RE: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt

[Hadriel Kaplan <[e-mail]>]

[note: I have not read Dale's comments yet, so there may be repeats (I started drafting this before getting his email)]

Technical:
Sec 5.2: I am really confused why this section exists.  The whole doc keeps repeating how TCP or SCTP alone (sans TLS) is not an appropriate connection for connection reuse, and indeed this section ultimately means the same.  So why is all the mechanics of this section in the doc?  Is there something different about TCP connection handling in this than previously?  Why is it even added to the alias table, when its entry cannot be used for aliasing?  This is quite confusing.  I recommend removing it.

Section 5.1, p.7: "P1 determines through RFC3263 server resolution process that the request should be sent to P2 on port 5061 using TLS..." and same thing on page 8 for P2.  Now I'm no expert, but last time I checked I thought SRV's allowed defining the port number, so one did NOT need to use the well-known 5061 for TLS, but could use anything.  So why is this restricting alias use to 5061 only?

Sec 9.3, p.15: the argument used here against TCP or SCTP connect-reuse (sans TLS) is one of malware hijacking on a multi-user computer.  I don't find that argument convincing, because I think it's a red herring.  If you have a malware program running on a proxy responsible for a domain, you are in a world of hurt regardless. (You're rearranging the deck chairs on the Titanic)  What *is* convincing is that without the certificate proof of identity inherent in TLS, the mechanism as defined in this draft would let a completely different machine, from a different IP, pretend to represent a legit domain's proxy by simply putting in the Via and alias param.  That would be bad.  And due to SCTP multi-homing coming from any IP, and load-balancing techniques and such, just restricting the source IP to avoid that problem won't work universally.  *That* should be the text in the draft for why TLS is required, vs. the "malware" excuse.  I am only mentioning this because not allowing TCP or SCTP alone is a major detractor for this draft, so the explanations for why not need to be strong.

Sec 8.1, p.11: Regarding TCP/SCTP connections, it says "Subsequent requests that resolve to the same IP address, port, and transport tuple MUST reuse the same connection."  Since when is that mandatory, and why?  There is no connection reuse for TCP/SCTP.  If I want to open two TCP connections to a server, for example due to head-of-line blocking or failure of previous, why can't I?  In fact, if I want to open two separate TLS connection why can't I?  This should at least only be a SHOULD strength.

Sec 8.1, p.11: Further, next sentence says "It MUST only accept responses over this connection and MUST NOT accept any requests over this connection."  Why is that?  The far-end chose to send a request over an open connection.  It's definitely not clear that the far-end should have done so (nor how it would have resolved to do so), but is there anything wrong from a protocol perspective with the local end accepting it?  For example if the far-end is manually configured to do so.

Sec 5.1, p.8 says: "The presence of the "alias" parameter indicates that P1 does support aliasing.  P2 now authenticates the connection (see Section 9.2) and if the authentication was successful, P2 creates an alias to P1 using the advertised address in the topmost Via."  This implies a server-side authentication occurs for the initial TLS connection, the request is sent from P1 to P2, P2 sees the alias, and then P2 does a TLS renegotiation to get the client side's cert?  I think it's important to spell this out in the draft, because I'm not sure everyone supports this after the initial TLS handshake is over (I think most mutual-TLS happens at the beginning in the real world, but I could easily be wrong - IANAE).


Editorial:
1) Sec 3, page 4: "While this is adequate for TCP, and indeed is the only way to securely do connection reuse over that transport (see Section 9.3..." the words "connection reuse" should be removed since it clearly does NOT reuse the connection in such a case.

2) Section 5 is a bit confusing, because the diagram shows two UA's and two proxies between them, then describes things in terms of "UAC" and "UAS", whereas I'm fairly sure you mean the proxies instead.  For example, second paragraph of sec 5.1 would imply the UAS uses P2's connection for all subsequent requests going to the UAC, which is NOT true.  If it has a record-route, then for in-dialog requests yes, but it has nothing to do with subsequent requests going to the UAC in general.

3) sec 5.2: "Connection reuse on the TCP transport is done differently from the TLS case."  No, it's not done at all.  There is no "reused connection".

4) sec 5.2 says "The presence of the "alias" parameter in the topmost Via for a TCP transport is not required."  Then later in section 8.1 it says "For TCP and SCTP transports, the client MUST NOT insert the "alias" parameter in the topmost Via header.." (also note the double-period at the end of that sentence)

-hadriel


> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > Sent: Wednesday, October 17, 2007 1:15 AM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: [Sip] I-D ACTION:draft-ietf-sip-connect-reuse-08.txt
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > > This draft is a work item of the Session Initiation
> > Protocol Working
> > > Group of the IETF.
> > >
> > >     Title           : Connection Reuse in the Session Initiation
> > >                           Protocol (SIP)
> > >     Author(s)       : R. Mahy, et al.
> > >     Filename        : draft-ietf-sip-connect-reuse-08.txt
> > >     Pages           : 21
> > >     Date            : 2007-10-16
> > >
> > > This document enables a pair of communicating proxies to reuse a
> > >    congestion-controlled connection between themselves for sending
> > >    requests in the forward and backwards direction.  Because the
> > >    connection is essentially aliased for requests going in the
> > > backwards
> > >    direction, reuse should be predicated upon both the communicating
> > >    endpoints authenticating themselves using X.509 certificates
> > > through
> > >    TLS.  For this reason, we only consider connection reuse for TLS
> > > over
> > >    TCP and TLS over SCTP.  A single connection cannot be reused for
> > > the
> > >    TCP or SCTP transport between two peers, and this
> > document provides
> > >    insight into why this is the case.  As a remedy, it
> > suggests using
> > >    two TCP connections (or two SCTP associations), each opened pro-
> > >    actively towards the recipient by the sender.  Finally, this
> > > document
> > >    also provides guidelines on connection reuse and virtual SIP
> > > servers
> > >    and the interaction of connection reuse and DNS SRV
> > lookups in SIP.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reu
> > > se-08.txt
> > >
> > > To remove yourself from the I-D Announcement list, send a
> > message to
> > > [e-mail] with the word unsubscribe in
> > the body of
> > > the message.
> > > You can also visit
> > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > to change your subscription settings.
> > >
> > > Internet-Drafts are also available by anonymous FTP. Login with the
> > > username "anonymous" and a password of your e-mail address. After
> > > logging in, type "cd internet-drafts" and then "get
> > > draft-ietf-sip-connect-reuse-08.txt".
> > >
> > > A list of Internet-Drafts directories can be found in
> > > http://www.ietf.org/shadow.html or
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > >     [e-mail].
> > > In the body type:
> > >     "FILE /internet-drafts/draft-ietf-sip-connect-reuse-08.txt".
> > >
> > > NOTE:       The mail server at ietf.org can return the document in
> > >     MIME-encoded form by using the "mpack" utility.  To use this
> > >     feature, insert the command "ENCODING mime" before the "FILE"
> > >     command.  To decode the response(s), you will need "munpack" or
> > >     a MIME-compliant mail reader.  Different MIME-compliant
> > mail readers
> > >     exhibit different behavior, especially when dealing with
> > >     "multipart" MIME messages (i.e. documents which have been split
> > >     up into multiple messages), so check your local documentation on
> > >     how to manipulate these messages.
> > >
> > > Below is the data which will enable a MIME compliant mail reader
> > > implementation to automatically retrieve the ASCII version of the
> > > Internet-Draft.
> > >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use
> > [e-mail] for questions on current sip
> > Use [e-mail] for new developments on the application of sip
> >
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip