Subject: [Sip] outbound-06 submitted

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 22 Nov 2006 13:26:09 -0800

Hi,

I submitted -06 of outbound so folks can at least take a look to see
that the many small changes we have agreed to have been incorporated.
I also included the proposed text for FASTEST, since the draft would
need significant surgery anyway if we go with CLEANEST.

Until it appears in the archive you can find it here:
http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-06.html
http://svn.resiprocate.org/rep/ietf-drafts/fluffy/draft-ietf-sip-outbound-06.txt

thanks,
-rohan

_______________________________________________
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: Klaus Darilion <[email-masked]>
Date: Mon, 27 Nov 2006 11:09:06 +0100

Hi Rohan!

I have a question regarding sending with TLS in section 4.3:

> 4.3  Sending Requests
> 
>    When a UA is about to send a request, it first performs normal
>    processing to select the next hop URI.  The UA can use a variety of
>    techniques to compute the route set and accordingly the next hop URI.
>    Discussion of these techniques is outside the scope of this document
>    but could include mechanisms specified in RFC 3608 [RFC3608] (Service
>    Route) and [I-D.rosenberg-sip-route-construct].
> 
>    The UA performs normal DNS resolution on the next hop URI (as
>    described in RFC 3263 [RFC3263]) to find a protocol, IP address, and
>    port.  For non-TLS protocols, if the UA has an existing flow to this
>    IP address, and port with the correct protocol, then the UA MUST use
>    the existing connection.  For TLS protocols, there MUST also be a
>    match between the host production in the next hop and one of the URIs
>    contained in the subjectAltName in the peer certificate.  If the UA
>    cannot use one of the existing flows, then it SHOULD form a new flow
>    by sending a datagram or opening a new connection to the next hop, as
>    appropriate for the transport protocol.

The UA is only allowed to reuse a TLS connection, if the host production 
of the next hop is also present in the subjectAltName of the peer's 
certificate. Otherwise it should open a new TLS connection to the next hop.

But as this new connection is sent to the same remote socket, it is very 
likely that the peer's certificate in the new TLS connection is the same 
as in the existing connection, unless the client and server are capable 
of the "Server Name Indication" TLS extension. Thus, what about 
suggesting this TLS extension?

regards
klaus

-- 
Klaus Darilion
nic.at