Subject: RE: [midcom] Protocol eval: RSIP 2.1.8 and 2.3.1 - 2.3.4 - Securi ty F-> T (was RE: Proposed changes to RSIP evaluation...

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 6 Aug 2002 08:40:21 -0400

We come to the same basic conclusion, but I should note that neither RFC
3102 nor RFC 3103 discusses the operation of the RSIP negotiation protocol
itself over IPSEC.  The extensive discussion in these documents is about the
IPSEC transport which RSIP negotiation enables (i.e. the subject matter of
the protocol, not the transport of the protocol).

-----Original Message-----
From: Barnes, Mary [NGC:B602:EXCH] 
Sent: Monday, August 05, 2002 3:42 PM
To: [email-masked]'; 'midcom'
Subject: [midcom] Protocol eval: RSIP 2.1.8 and 2.3.1 - 2.3.4 - Security
F-> T (was RE: Proposed changes to RSIP evaluation...

Hi all,

Given that the RSIP protocol does define the use of IPSEC, I would agree
that these could be changed to T.  The current text description in section
2.3.1 is fairly informative, do you really want to replace that with the
single sentence or do you want the information combined?  Also, I did not
see any reference to TLS in the RSIP RFCs, so I would propose to just add
the reference to IPSec, or perhaps I somehow missed the reference. Note,
that this would also require a change to the conclusion. 

Again, WG feedback (i.e. if you don't agree with changing these to T),
should be sent by COB on Tuesday, August 5th. 

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, August 04, 2002 10:42 PM
To: 'midcom'
Subject: Re: Proposed changes to RSIP evaluation (was RE: [midcom]
Comments on protocol evaluation draft

---text deleted -----------

>
> Now, you're also proposing that RSIP be "upgraded" for the security
> onesthat you had scored as Failing to meet compliancy in your analysis.
> Based upon the text currently in section 2.1.8, 2.3.1, which also
> applies to 2.3.2-2.3.4, I don't have a problem changing those to Ps.
>

MEGACO and DIAMETER do not have "native" support for capabilities
satisfying these requirements, they depend on operation over, e.g.,
TLS or IPsec to satisfy them, and they were scored a T. RSIP is no
different: no native support; but the cappability can be added by
operating over TLS or IPsec; so, it too should be scored a T. All I'm
asking for here is consistency of scoring for all the protocols.

Additionally, the "native" communications between hosts and RSIP gateways
is over tunnels for the data connections. Although not explicitly stated,
the preferred operation of the control channel is over that same tunnel.
If that tunnel is IPsec, then the control channel is secured. At least
with RSIP, the tunnel is already there.

At to replacement for the RSIP portions of the text following requirements
2.1.8, and 2.3.1 through 2.3.4, I would suggest:

     RSIP does not have "native" support for this capability, but the
     capability can be obtained by operating RSIP over TLS or IPsec.

>
> The P+ category would only apply if these changes could be made to
> RSIP as a natural extension of the protocol with no impact to current
> users of that protocol (i.e. current users don't make use of the
> information, and wouldn't be bothered by it being in the messages).
>

If the score for these requirements is not to be T, then ....

---Remainder of email thread deleted----

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom