Subject: [Sip] comments on connect-reuse

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Mar 2005 16:38:10 -0500

I think the draft needs to be very clear on its relationship to 
jennings-sipping-outbound. I think the delineation are:

1. connect-reuse focuses on proxy to proxy relationships, and as a 
result have a different trust model than client to proxy, which is the 
focus of the jennings draft

2. connect-reuse has both sides of the connection with entries in the 
DNS corresponding to them, not so for the jennings-outbound draft

3. the problem statement for connect-reuse is reducing connection 
overheads by reuse; its still possible to connect in the reverse direction

there are probably others.

I think section 2.2 should be removed entirely, at that is now addressed 
elsewhere. Connect-reuse actually says that this is so, but nonetheless 
includes this text that doesn't really belong here.

> If the Transport layer had
>    some way to associate these connections, then request and responses
>    originated from either node could reuse existing connections as shown
>    below.
> 
>           +-----------+                        +-----------+
>           |           |                        |           |
>           |   Node A  | 8293              5061 |   Node B  |
>           |           |<======================>|           |
>           |           |                        |           |
>           +-----------+                        +-----------+

but this is not the desired behavior. We talked about this at the last 
meeting. You want to load balance, so you can't just reuse an existing 
connection to node A, since then the other nodes in the the cluster on 
side A would never receive traffic.

>  When SIP entities use a connection oriented protocol to send a
>    request, they typically originate their connections from an ephemeral
>    port.  The SIP protocol includes mechanisms which insure that

expand SIP

>  but uses an ephemeral port (port 8293) for a new connection to Entity
>    B.  These entities could be SIP User Agents or SIP Proxy Servers.

need to carefully define entities here so as to not overlap with 
jennings-outbound

> The SIP protocol includes mechanisms which insure that responses to a
>    request reuse the existing connection which is typically still

ensure, not insure

> This is especially
>    problematic for some common SIP call flows (for example, the
>    recommended example flow in figure number 4 in RFC3725 [9] (SIP
>    third-party call control) use many reINVITEs.

s/use/that use

> Similarly, when when an "outbound-only" user agent opens a connection
>    to only one proxy server in the same cluster, there is no way for
>    this user agent to receive incoming requests if the this particular
>    proxy goes down.  In many scenarios, the user agent would not notice
>    the connection was unresponsive until it was time to refresh its SIP
>    registration.  Some "outbound-only" user agents would like the
>    ability to open persistent connections to more than one proxy server
>    in a cluster, so that at least two proxy servers in the cluster can
>    forward incoming requests to the user agent.  This requirements of
>    these "outbound-only" user agents are discussed in [1].

suggest removing this paragraph as well

>  1.  A connection sharing mechanism SHOULD allow SIP entities to reuse
>        existing connections for requests and responses originated from
>        either peer in the connection.

i think its just requests. connection reuse for responses is specified 
in rfc3261

> There is no requirement to share a complete path for ordinary
>        connection reuse.  Hop-by-hop connection sharing is more
>        appropriate.

its also not a requirement to cure cancer. I don't think 
non-requirements belong.

Also, suggest focusing on clarifying the requirements as different from 
sipping-outbound

> 4.  Behavior

per sip-guidelines, you want to clearly specify behavior for transaction 
clients and transaction servers. The current text doesn't really 
differentiate, and is lacking important normative behaviors as a result. 
In fact, there are very few rfc2119 terms in here, though several 
important behaviors are specified.

>  connection stays up.
>       The SIP community recommends that servers keep connections up
>       unless they need to reclaim resources, and that clients keep
>       connections up as long as they are needed.  Connection reuse works
>       best when the client and the server maintain their connections for

why is this indented?

>  To implement connection aliases for explicit IP addresses and port
>       numbers, 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 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.

can't parse this

>   transport is selected, an SRV lookup would ordinarily occur to find
>    the appropriate port number. 

it is used to find IP address and port.

> In this case, the transport layer uses
>    a connection reuse alias instead of performing the SRV query.

this means that the load balancing and prioritization propertise of the 
DNS entries are lost. I think this is not acceptable.

Also, there are no normative statements about this behavior.

> The Via sent-by address needs to be within the
>    scope protected by the certificate presented by the originator during
>    TLS mutual authentication and the received IP address needs be a
>    valid IP address for the sent-by host or hosts.  In other words, the
>    sent-by address MUST be resolvable from the subjectAltName of the
>    originator certificate, and the received IP address MUST be
>    resolvable from the sent-by address.  This is in addition to other
>    requirements for TLS authentication and authorization discussed in
>    SIP [3] and Locating SIP Servers [6].
> 
>    Following this logic step-by-step:

this first paragraph is sort of explanatory in nature, and it is 
followed by much more rigorous protocol specifications. However, this 
explanatory bit contains normative text that could be interpreted as 
being different than the specific behaviors in the steps that follow. In 
particular, "MUST be resolvable from the...". Suggest rewording the 
first paragraph to summarize the technique.

  >    If the advertised address and the subjectAltName match exactly
>        then the certificate covers the address.

need to specify matching rules. Also, what if the subjectAltName has 
another form besides a hostname? I believe they can contain all kinds of 
identifiers.

> Use DNS to resolve if the advertised name is resolvable from the
>        subjectAltName (start by resolving the subjectAltName as if it
>        where a target URI according to the rules in RFC3263.  That is,
>        if no port number is present perform an SRV lookup, then finally
>        resolve relevant address records).  

the stuff inside of the () is quite fundamental behavior. There is no 
reason it should be inside of ().

As above, this resolution technique is dependent on the form of 
subjectAltName. You need to constrain it.

Also, the processing in RFC3263 starts with a NAPTR lookup. You are 
going right to SRV. Also, you need to specify how to transform the 
subjectAltName into a SIP URI for purposes of doing rfc3263 processing, 
since that spec starts with a SIP URI as input.

> Finally, Verify that the advertised address can resolve to the IP
>        address over which the connection was received.

Note well: this rules this mechanism out if there is a NAT between them. 
Also, you need to define what it means to "resolve". Using rfc3263? How? 
using A records?

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

I am still not sure why the alias needs to be explicitly signaled. Why 
can't the receiving proxy merely make a decision on whether to do this?

> The mechanism in this document can significantly improve the security
>    of SIP networks, in that it makes SIP over TLS (and the sips: scheme)
>    practical for devices which do not have a certificate rooted in a
>    well-known certificate authority.

this needs to be removed

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

you need to cite the URI that defines the registry

> 8.1  Normative References
> 
>    [1]  Jennings, C., Ed. and A. Hawrylyshen, Ed., "SIP Conventions for
>         Connection Usage", draft-jennings-sipping-outbound-00 (work in
>         progress), October 2004.

why is this a normative requirement?

>  [2]  Rosenberg, J., "Obtaining and Using Globally Routable User Agent
>         (UA) URIs (GRUU) in the  Session Initiation Protocol (SIP)",
>         draft-ietf-sip-gruu-02 (work in progress), July 2004.

same with this one

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   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