Subject: [Sip] comments on draft-ietf-sip-connect-reuse-05

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jul 2006 00:22:00 -0400

>   the connection.  SIP entities that can only open a connection in a
>    specific direction -- perhaps because of Network Address Translation
>    (NAT) and firewall reasons -- reuse their connections using the
>    mechanism described in [1].

another important reason is that, in the case of TLS, only one side will
offer a certificate. In other words, connect-reuse only applies in truly
symmetric models.

>  Opening an extra connection where an existing one is sufficient can
>    result in potential scaling and performance problems.  Consider the
>    call flow shown below where Proxy A and Proxy B use the Record-Route
>    mechanism to stay involved in a dialog.  Proxy B will establish a new
>    TLS connection just to send a BYE request.

this presumes in general that there aren't persistent, long-lived
connections already set up.

>  Opening an extra connection where an existing one is sufficient can
>    result in potential scaling and performance problems.  Consider the
>    call flow shown below where Proxy A and Proxy B use the Record-Route
>    mechanism to stay involved in a dialog.  Proxy B will establish a new
>    TLS connection just to send a BYE request.

the bottom of section 3 already talked about benefits; you should
combine together into one place.

> This effectively doubles the load on each
>    entity. 

definitely not.

It doubles the amount of work for connection establishment, but its far
from obvious to me in most use cases that the overall work of the proxy
is dominated by connection establishment. Today, for the vast majority
of cases, there are fairly fixed relationships between proxies and this
mechanism won't impact the workload at all. This only starts to show up
as an issue in cases of broad interconnection across numerous domains
(i.e., every enterprise connects to every other enterprise). Again
though I wonder if the connection establishment is really the dominant
CPU cost.

>  ReINVITEs or UPDATE [7] requests are expected to be handled
>    automatically and rapidly in order to avoid media and session state
>    from being out of step.  If a reINVITE requires a new TLS connection,
>    the reINVITE could be delayed by several extra round-trip times.
>    Depending on the round-trip time, this combined delay could be
>    perceptible or even annoying to a human user. 

Can you give a specific use case? I don't think there are established
guidelines for how long it takes to add video, for example.

>  The act of reusing a connection is initiated by an user agent client
>    (UAC, or the proxy half of the UAC) when it adds an "alias" parameter
>    to the added Via header (the parameter itself is defined later).
>    When a user agent server (UAS, or the proxy half of the UAS) receives
>    the request, it examines the topmost Via header. 

I think you mean just 'client' and 'server' which are well defiend in
rfc3261, and are what you want. 'proxy half of a UAC' makes no sense.

> Without any loss of
>    generality, it should be clear that the same technique can be used
>    for connection reuse between a UAC and an edge proxy, or between an
>    edge proxy and a UAS, or between an UAC and an UAS.

Just talk about clients and servers.

> The presence of the "alias" parameter indicates that P1 does support
>    aliasing.  P2 now authenticates the connection and if the
>    authentication was successful, P2 creates an alias to P1 using the
>    advertised address in the topmost Via.

Firstly, you need to define 'successful' authentication. You need to
match the domain in the certificate with the via address. Also, this
last sentence is very confusing, since the table is NOT populated with
the advertised address, its populated with the received address, as
described in the text below.

Also how do you populate destination port? The overview section doesn't
say. I believe it is NOT the received port (as IP address is) but rather
the one advertised in the sent-by field, or 5061 (the default) if no
port is listed.

> To implement connection aliases for resolved addresses, a SIP node
>    could (for example) search an additional data structure (the alias
>    table) prior to opening a new connection, or could modify the data
> 
> 
> 
> Mahy, et al.             Expires August 5, 2006                 [Page 7]
> 
> Internet-Draft            SIP Connection Reuse             February 2006
> 
> 
>    structure in which it keeps active connection state so that aliases,
>    active connections, and blacklisted nodes are all discovered when
>    looking for an active connection.

you've not defined 'an additional data structure' or blacklisted nodes;
I couldn't follow this paragraph.

> 6.  Requirements

you may want to have an intro paragraph which says that these are the
requirements which motivated this specification

> 7.  Formal Syntax
> 
>    The following syntax specification uses the augmented Backus-Naur
>    Form (BNF) as described in RFC 4234 [6].  This document extends the
>    via-params to include a new via-alias defined below.

please use the =/ syntax notation that we've started using for sip
specs. Its much better.

>  request.  Whenever the RFC3263 server selection mechanism executed at
>    the receiver results in the choice of this IP address, port, and
>    transport tuple, the alias MUST be used instead.

I think a SHOULD is fine here; and indeed if the connection has gone
away you obviously won't be reusing the alias.

> An alias is formed at the sender of the request when it executes the
>    RFC3263 server selection mechanism to arrive at an IP address, port,
>    and transport tuple to send a request to.  Subsequent requests going
>    to the same destination address MUST use the alias instead.

Hmm this MUST is stronger than in rfc3261, which actually says SHOULD. I
think the existing SHOULD is fine.

>  Only one alias SHOULD exist for the resolved address.  If more than
>    one alias is requested because of race conditions (or any other

I don't think the SHOULD here is capitalized; you're not specifying an
action to take.

You need to define 'resolved address'. I don't know what that is.

> Because an alias connection might be reclaimed during a transaction,
>    clients SHOULD NOT enforce the RFC 3261 requirement of sending CANCEL
>    and ACK (for non 2xx responses) to the same port.  If the alias
>    connection no longer exists, the client SHOULD open a new connection
>    to the resolved address and send the CANCEL or ACK there instead.
>    The newly opened connection MAY be inserted into the alias table.

Hmm. I think this rule only applies to aliases formed through the
mechanism defined here, NOT through the ones obtained from rfc3263.

> And furthermore,
>    it MUST reuse the connection when subsequent requests in the same or
>    different transactions are destined to the same resolved address.

Again per above, I think this is SHOULD. Generally with all of these
reuse requirements SHOULD is OK.

>  Whether or not to allow an aliased connection ultimately depends on
> 
> 
> 
> Mahy, et al.             Expires August 5, 2006                 [Page 9]
> 
> Internet-Draft            SIP Connection Reuse             February 2006
> 
> 
>    the recepient of the request.  

I think you mean that a client gets no confirmation that its downstream
peer created the alias, or indeed that it even supports this specification.

> Clients must authenticate the connection before forming an alias.
>    Section 9.1 discusses the authentication steps in more detail.

You need to integrate that processing as part of the core client and
server behaviors.

> A TLS server conformant to this specification MUST ask for a client
>    certificate; if the client possesses a certificate, it will be
>    presented to the server for mutual authentication.  The server MUST
>    ensure that the canonical host name of the client is present either

where does one obtain the canonical hostname?

It seems to me, that in a proxy to proxy case, the receiving proxy (the 
server side) will need to check the record-route hostname against the 
client certificate.

> This document adds a parameter to the SIP header field parameters
>    registry:

reference rfc3968

>  Reference:  This document

Should say: RFC XXXX [[NOTE TO RFC-EDITOR: please replace with the final 
RFC number of this specification]]

> 13.1  Normative References
> 
>    [1]  Jennings, C. and R. Mahy, "Managing Client Initiated Connections
>         in the Session Initiation  Protocol (SIP)",
>         draft-ietf-sip-outbound-01.txt (work in progress), October 2005.

I dont think this is a normative reference.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sat, 08 Jul 2006 02:07:20 -0500

Jonathan: Thanks for a detailed read.  A lot of your comments
were incorporated as requested; below are the remaining
comments that warranted a discussion.

Jonathan Rosenberg wrote:
> another important reason is that, in the case of TLS, only one side 
> will offer a certificate.

Is that always true?  After all, a server can ask a client of
a certificate as well.  If the client is a proxy, it will have one,
and it will give it to the server.  In connect-reuse, if
mutual authentication is to be done, the server has to authenticate
the client as well.  An attempt on how it does that is  is teased
out in domain-certs (more on that in a separate email thread).

> connections already set up.

Which is reasonable today, since there are no guidelines for
persistent long-lived connections in rfc3261.  Instead it talks
about general reuse of connections without specifying anything else.
Maybe some will say that how to do this is implementation defined,
but I think that we ought to be able to provide some more stricter
guidelines to implementors, especially as TCP and TLS become the
dominant transports.  Otherwise it is already a mess for TCP,
where some implementations keep the connections open across
transactions and dialogs, some do not, and yet others open a new
connection to send a response!  Let's not create the same mess for
TLS.

>> This effectively doubles the load on each entity.
> 
> definitely not.
> 
> It doubles the amount of work for connection establishment, [...] 
> Again though I wonder if the connection establishment is really the 
> dominant CPU cost.

In "SSL and TLS" by EKR, Section 6.19 analyzes TLS connection
establishment.  Servers will build up considerable queues as
the server CPU saturates by the SSL handshakes it is already
performing.

>  guidelines for how long it takes to add video, for example.

No, they are not.  However, it is appropriate that a re-INV
over an existing TLS connection will complete faster than one
that requires SSL handshake.

>> The presence of the "alias" parameter indicates that P1 does 
>> support aliasing.  P2 now authenticates the connection and if the 
> match the domain in the certificate with the via address.

Good point about defining 'successful' authentication.  I have
tried to do highlight the issue of a server authenticating a
client in domain-certs.  Via is the only obvious choice here.

> Also, this last sentence is very confusing, since the table is NOT
> populated with the advertised address, its populated with the
> received address, as described in the text below.

I will clarify.

> Also how do you populate destination port? The overview section 
> doesn't say. I believe it is NOT the received port (as IP address is)
>  but rather the one advertised in the sent-by field, or 5061 (the 
> default) if no port is listed.

Yes; I will clarify.

>> structure in which it keeps active connection state so that 
>> aliases, active connections, and blacklisted nodes are all 
>> discovered when looking for an active connection.
> 
> you've not defined 'an additional data structure' or blacklisted 
> nodes; I couldn't follow this paragraph.

I will rephrase and clarify.

>  requirements which motivated this specification

Sure.

>> 7.  Formal Syntax
[...]
> please use the =/ syntax notation that we've started using for sip 

Sure.

>> request.  Whenever the RFC3263 server selection mechanism executed 
>> at the receiver results in the choice of this IP address, port, and

I can clarify the corner case.  But I really think that the
normative strength should be MUST.  The more choices, the
more complexity.  Think of it from an implementation point
of view: if an alias exists, why not use it instead of
opening up a new connection?  If you open up a new connection,
then do you put it in the alias table?  If you do, then you
have two aliases.  How do you choose which one to use on
subsequent requests?

>> An alias is formed at the sender of the request when it executes 
>> the RFC3263 server selection mechanism to arrive at an IP address, 
>> port, and transport tuple to send a request to.  Subsequent 
>> requests going to the same destination address MUST use the alias 
>> instead.
> 
> Hmm this MUST is stronger than in rfc3261, which actually says 
> SHOULD. I think the existing SHOULD is fine.

Yes, rfc3261 says SHOULD (actually RECOMMENDED is the word used
there).  But for the same reason I wrote above, it will be
good to reuse the same alias.

> It seems to me, that in a proxy to proxy case, the receiving proxy 
> (the server side) will need to check the record-route hostname 
> against the client certificate.

R-R is optional.  The only header that fits the bill is Via.

Thanks so much for a detailed read.  Much appreciated.

Ciao.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)