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

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sat, 10 Nov 2007 14:27:32 +0100

(As WG chair)

We haven't exactly had the best response to this reissue of the WGLC.

There were a good 10 or 12 of you (at least) in the last IETF meeting
who said you needed this document. That means I am expecting 10 or 12
last call comments from you because you will have read the document. 

I am going to assume that as there was a delay in one of the critical
references being produced, this gave you problems. These documents are
now at:

http://www.ietf.org/internet-drafts/draft-ietf-sip-domain-certs-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-00.txt

Note that while comments on these two documents are welcome, please use
a separate thread for such comments, and restrict this thread to WGLC
comments on connect-reuse, which can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-08.txt

I am going to extend this WGLC for a further two weeks until 24th
November - please read and respond on this document by then.

Regards

Keith

> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: Tuesday, October 23, 2007 6:24 PM
> To: [email-masked]
> Subject: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt 
> 
> (As WG chair)
> 
> Here we have a document that has been floating around for a 
> while. We had a WGLC on it back on 26th October 2005 to 
> complete 18th November 2005. After that we got buried in 
> outbound, and sort of lost direction.
> 
> At the last IETF meeting, we agreed to rescope this and as a 
> result decided there support in progressing the document. You 
> can find the record of that discussion in the proceedings for 
> IETF#69. This draft reflects those WG decisions. 
> 
> We would therefore like to renew the WGLC, and solicit 
> comments by close of business on Tuesday 6th November on 
> draft-ietf-sip-connect-reuse-08.
> 
> Normal rules apply. Comments to the sip mailing list and 
> authors. Please clearly identify the nature of your comment 
> (editorial, minor technical, major). Please clearly identify 
> the text to which your comment relates.
> 
> Note that of the normative references, domain-certs is in 
> progress as a WG item, and we should see a first draft of the 
> WG text in the next few days.
> 
> Regards
> 
> Keith
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Wednesday, October 17, 2007 1:15 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > 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 
> > [email-masked] 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:
> > 	[email-masked].
> > 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 
> [email-masked] for questions on current sip 
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Sun, 11 Nov 2007 17:08:59 -0500

Comments on draft-ietf-sip-connect-reuse-08.

Overall:

The mechanism defined in this I-D is sensible and useful.  The writing
could be improved significantly.

Major technical:

Section 10, "Support for Virtual Servers" explains the necessity of
certain elements of the connection-reuse mechanism.  But as far as I
can tell, this explanation is incorrect (although the problem is
real).

It's a bit hard to follow the flow that is described in this section,
it seems to involve five SIP agents, only one of which has a name
("P1") and one a description ("Alice's proxy"), leaving three unnamed.
But it looks like the first step is when a proxy P1 (that is
responsible for two domains) establishes a connection to Alice's
proxy, and Alice's proxy "establishes an alias" for it, that is,
decides that the connection is usable for requests in the reverse
direction.

The second step is when a request originating from a different one of
P1's domains passes through P1 and then to Alice's proxy, causing
Alice's proxy to establish an alias for the second connection, of
course, as an alias for the same address, that of P1.

This is then supposed to lead to the inability of P1 to correctly
route requests that arrive on the connection.  This seems to involve a
binding between the connection and the ultimate destination of the
request.  But that is not possible, because as a proxy, P1 must take
into account the domain-part of the request URIs of the requests.
This seems to be related to this sentence, which is meaningless on the
face of it:  "But that entry is now aliased to a connection with
[email-masked]."  Of course, a connection is with a host, not
with a SIP URI.  (Might this be a residuum of an older path-oriented
connection reuse concept?)

However, the virtual server problem is quite real.  The fundamental
problem is that making a TLS connection to a destination involves two
distinct steps -- first, using RFC 3263 to find the address of the
destination, then second, using TLS to establish *and authenticate* a
connection.  Only if both steps succeed is the connection available
for sending the message.  As such, the "alias table" must cache not
only which connections go to which destination addresses, but which
connections have authenticated themselves as responsible for which SIP
domains.  If a message is to a *new* SIP domain that resolves to an
address with a cached connection, the cached connection cannot be
used, because the connection is not authenticated for the new domain.

(Which suggests that a proxy serving multiple domains should be able
to present during TLS authentication certificate(s) that include all
the domains that it is responsible for, so that the connection can be
used for requests to all of those domains.)

Editorial:

Overall

Excessive text is spent on the cases of TCP and SCTP without TLS.  As
far as I can see, they are to be handled exactly as previously.  It is
useful to explain why this must be so, and section 9.3 does so, but I
don't see the need for the page-long section 5.2 and 5.3.

The description focuses on the "alias table", making that particular
implementation quasi-standard.  But I don't see the mechanism as being
complex enough to require describing that specific implementation in
order to make the mechanism clear.

A few definitions are given, but various terms that are used with new
meanings are not defined.  E.g., "establish an alias" meaning "the
destination of a connection deciding that the connection can be used
in the reverse direction, that is, for sending requests".

Examples tend to discuss multiple user agents and proxies, when the
entirety of the mechanism can be described by considering only the two
SIP agents at the ends of the connection.  I think the intention is to
make the examples more realistic, but instead the examples get more
complex and hard to follow -- especially because the discussions often
aren't meticulous about specifying which agent sends which message to
which agent.  (Not to mention that the discussion suggests that user
agents and proxies might participate in this mechanism in different
ways, whereas connection-reuse treats user agents and proxies
identically.)

The use of "alias descriptor" is unfortunate.  To start with, it is
confusing -- initially I mistook it for some sort of identification of
the row of the alias table.  But the concept of "descriptor" as being
a small integer identifying a network connection, as well as the very
term "descriptor", are Unix-specific.  Much better would be to use a
neutral term like "internal connection identifier" and to represent
the value by something like "XXXX".

There is an overall conflating of two concepts as "connection reuse".
One is using one connection to send more than one request from one
sender to one recipient.  The second is using one connection to send
requests in both directions.  The first concept is already supported
by RFC 3261; the second is what is being enabled by this I-D.  But the
I-D implements both actions using one alias table, obfuscating the
distinction and so obfuscating the changes that the I-D is
introducing.

Details

Section 5

- "P1 and P2 are proxies responsible for routing SIP requests through
user agents that use them as edge proxies (see Figure 4)."

Should that be "routing SIP requests *to* user agents"?

Section 5.1

- "Upon connection authentication and acceptance, P1 adds P2s to its
alias table."

"P2s" should be "P2".

- The text uses the phrase "items of interest in the alias table" when
it means "description of the values in the alias table".

- In both enumerated lists, the texts starting "At some later time"
should be separated into an independent paragraph, outside of the
enumerated lists, because they concern a different topic than the data
in the alias table.

- "When the server, P2, receives the request, it examines the topmost
Via to determine whether P1 supports aliased connections.  ...  The
presence of the "alias" parameter indicates that P1 does support
aliasing."

This should be rephrased, since the presence of "alias" means that the
initiating SIP agent is willing to use *this* connection in the
reverse direction:  "When the server, P2, receives the request, it
examines the topmost Via to determine whether P1 is willing to use
this connection for an aliased connection.  ...  The presence of the
"alias" parameter indicates that P1 supports aliasing on this
connection."

Section 8.1

- "The implications of placing an "alias" parameter in the topmost Via
header of a request must be understood by the client.  Specifically,
this means that the client MUST keep the connection open for as long
as the resources on the host operating system allow it to, and that it
MUST accept requests over this connection -- in addition to the
default listening port -- from its downstream peer."

It would seem obvious that the implications of inserting "alias" must
be understood by the client that does so.  A better wording would be:
"If the client places an "alias" parameter in the topmost Via header
of a request, the client MUST keep the connection open for as long as
the resources on the host operating system allow it to, and that it
MUST accept requests over this connection -- in addition to the
default listening port -- from its downstream peer."

- "Whether or not to honor an aliased connection ultimately depends on
the policies of the server.  It MAY choose to honor it, and thereby
send subsequent requests over the aliased connection."

This wording suggests that somehow the connection "is aliased" whether
or not the server even understands connection-reuse.  It would be less
awkward to say:  "Whether or not to use in the reverse direction a
connection marked with "alias" ultimately depends on the policies of
the server."

Section 9.3

- "This manner of opening connections, while still not secure, is at
least much more apparent and direct than using the connection reuse
mechanism over TCP or SCTP in an unauthenticated fashion."

What is the technical definition of "apparent and direct"?  I would
suggest "... is at least more secure than ...".

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Nov 2007 13:31:05 -0500

[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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 16 Nov 2007 11:07:02 -0600

[email-masked] wrote:
> The mechanism defined in this I-D is sensible and useful.  The
> writing could be improved significantly.

Dale: Thank you for your in-depth review and feedback.  More inline.

> can tell, this explanation is incorrect (although the problem is 

I suspect we are not that far apart in the understanding of the problem.
In other words, the problem is indeed, as you write:

> connections have authenticated themselves as responsible for which
> SIP domains.  If a message is to a *new* SIP domain that resolves to
> an address with a cached connection, the cached connection cannot be 

That is precisely why the alias table supports the "Destination
Identity" column.

I take it that the text describing the virtual server problem needs
to be made much more clear.  I will do so in the next revision,
using your comments as a guideline.

>  far as I can see, they are to be handled exactly as previously.  It
> is useful to explain why this must be so, and section 9.3 does so,
> but I don't see the need for the page-long section 5.2 and 5.3.

By "exactly as previously", do you mean handled as TLS?  If so,
then I would disagree since for the TLS case, you can indeed only
use one connection, but for TCP and SCTP without TLS you will
need two connections.  S5.2 disambiguates TCP connection reuse
from TLS reuse, thus I believe it is relevant (S5.3 is basically
a short two-paragraph section discussing SCTP for completeness.)

> implementation quasi-standard.  But I don't see the mechanism as
> being complex enough to require describing that specific
> implementation in order to make the mechanism clear.

The intent is not to make the alias table quasi-standard.  Rather,
it is easier to follow the subsequent discussion based on the
information presented in tabular format.  In reality, many robust
SIP implementations probably already include such a table anyway.  So
I do not see the harm in the continued use of the metaphor.

> in the reverse direction, that is, for sending requests".

OK; I will go through and attempt to catch some of the undefined
terms.

> entirety of the mechanism can be described by considering only the
> two SIP agents at the ends of the connection.  I think the intention
> is to make the examples more realistic, but instead the examples get
> more complex and hard to follow -- especially because the discussions
> often aren't meticulous about specifying which agent sends which
> message to which agent.  (Not to mention that the discussion suggests
> that user agents and proxies might participate in this mechanism in
> different ways, whereas connection-reuse treats user agents and
> proxies identically.)

Correct; any remaining ambiguity you see is my failure at
delineating what belongs to outbound and what should remain in
connect-reuse.  I will be more diligent about this in the next
revision.

> confusing -- initially I mistook it for some sort of identification
> of the row of the alias table.  But the concept of "descriptor" as
> being a small integer identifying a network connection, as well as
> the very term "descriptor", are Unix-specific.

Anything wrong with that :-) ?

> Much better would be to use a neutral term like "internal connection
> identifier" and to represent the value by something like "XXXX".

As a programmer, I find it convenient to refer to the connection
identifier as a descriptor.  With your permission, I would like to
continue using that analogy.

> by RFC 3261; the second is what is being enabled by this I-D.  But
> the I-D implements both actions using one alias table, obfuscating
> the distinction and so obfuscating the changes that the I-D is 
> introducing.

So this is an interesting and very relevant comment.  You are
absolutely right that there are indeed two concepts of connection
reuse.  However, I do not believe that the draft conflates them.

What you term as the "first concept" is indeed mentioned in rfc3261,
but not in the form that connect-reuse is exalting.  More specifically,
S18 of rfc3261 talks about persistent connections, and how an
implementation should keep connections open to send subsequent
requests over the same connection.  However, rfc3261 also mentions
that the duration a connection stays open should be at least as
long as 64*T1 seconds.  Thus, I have observed implementations that
keep a connection open as long as 64*T1 seconds and no more, and
some even less than that.

As a result of that observation, the text in connect-reuse exhorts
implementations to keep the connection open for as long as they can
(i.e., close it when resources need to be reclaimed using some
strategy like closing the least actively used connection, or the
connection that has been open for the longest time, etc.)

> Details
[...]

All of the details you point here are excellent, and will be
included in the next revision of the draft.

Thanks for the WGLC review, Dale.

Regards,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: [email-masked]
Date: Fri, 16 Nov 2007 13:11:06 -0500

From: "Vijay K. Gurbani" <[email-masked]>

   > but I don't see the need for the page-long section 5.2 and 5.3.

   By "exactly as previously", do you mean handled as TLS?

No, as described in RFC 3261.

The problem I see is that the table is not labeled as a mataphor; it
is described as if its existence is mandatory.  But what the standard
will actually prescribe is the *behavior* that is carried out by the
example mechanism you are describing; if it is possible to do so
without confusion, it is better to explicitly describe the behavior
(and especially making clear the allowed variations) than to describe
a mechanism and then imply (but not state) "you have to make it act
like this".

Not specifying behavior explicitly leads to versions of the "implement
to example" problem that has plagued SIP since the early days.

In a standard?

As a standards weenie, I would say that the less we incorporate of
specific implementations, the better.  We are already plagued by
programmers who cannot analyze something without visualizing one,
specific, concrete example, and as a consequence they do not envision
the range of possibilities that the standard admits, leading to all
sorts of errors.  We should not encourage that.

It's using the same word for both, which requires very close reading
to figure out which concept is being talked about at which time.  (I'm
not claiming that *you* don't keep the two ideas straight, but I'm
worried about the next 200 readers.)

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Nov 2007 14:14:38 -0500

> From: [email-masked] [mailto:[email-masked]]
>

Indeed, I had the exact same confusion and I'm worried about the next 199 too.  :)  I would call it "persistent connection", a la HTTP.

With regards to TCP "persistent connection", where you mean the client can reuse the same TCP connection for requests going to the same server, is that really necessary to put in a standard?  I mean it was always allowed, no?  I guess it's good to make it explicit, but I'm not sure how one knows when it's the right thing to do or not.

I agree there are clients creating new TCP connections per SIP session, and tearing down old ones, and that's very bad in some situations, but it's essentially a local policy decision.  A client is free to open and close TCP connections at will.  You can't make it keep one open forever.  And there is nothing that the signaling is doing about it to help in this draft.  Like for example if the server side stuck something in the response to indicate "you may keep this connection open and send any future requests to me over it if you can". (i.e., the Connection/Keep-Alive header model as in HTTP)

Some vendors restrict how many simultaneous connections they'll allow from the same client, for security reasons, so are you thinking along those lines?

-hadriel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 16 Nov 2007 14:48:12 -0600

[email-masked] wrote:
vkg>    By "exactly as previously", do you mean handled as TLS?
> No, as described in RFC 3261.

OK; I will wordsmith some text to refer to rfc3261.

> example mechanism you are describing; 

I think you are being too literal about the table; the table itself
is first described in S5, the opening paragraph of which is: "This
section is tutorial in nature, and does not specify any normative
behavior."  Thus, I do not see how one can construe that the existence
of the table is mandatory.  Furthermore, rfc3261 essentially uses
the same information in S18, where it talks about "These connections
are indexed by the tuple formed from the address, port, and transport
protocol at the far end of the connection."  The table in connect-
reuse is the same information, albeit in an easy to visualize manner.
I really do not see the harm.

> to example" problem that has plagued SIP since the early days.

"Implement to example" in SIP has resulted because either there
are many ways to do the same thing, or because due to insufficient
guidance, a developer latches on to an example and considers that
the canonical form for doing something in SIP.

I don't see how presenting information in a tabular forFrom [email-masked] Fri Nov 16 15:48:27 2007
Date: Fri, 16 Nov 2007 14:48:12 -0600
From: "Vijay K. Gurbani" <[email-masked]>
Organization: Bell Labs Security Technology Research Group
To: [email-masked]
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Cc: IETF SIP List <[email-masked]>

[email-masked] wrote:
vkg>    By "exactly as previously", do you mean handled as TLS?
> No, as described in RFC 3261.

OK; I will wordsmith some text to refer to rfc3261.

> example mechanism you are describing; 

I think you are being too literal about the table; the table itself
is first described in S5, the opening paragraph of which is: "This
section is tutorial in nature, and does not specify any normative
behavior."  Thus, I do not see how one can construe that the existence
of the table is mandatory.  Furthermore, rfc3261 essentially uses
the same information in S18, where it talks about "These connections
are indexed by the tuple formed from the address, port, and transport
protocol at the far end of the connection."  The table in connect-
reuse is the same information, albeit in an easy to visualize manner.
I really do not see the harm.

> to example" problem that has plagued SIP since the early days.

"Implement to example" in SIP has resulted because either there
are many ways to do the same thing, or because due to insufficient
guidance, a developer latches on to an example and considers that
the canonical form for doing something in SIP.

I don't see how presenting information in a tabular format leads
to implementation by example.  There is ample additional text
that explicitly specifies the behavior.

>    Anything wrong with that :-) ?

Sure ... this is the IETF, right?  This protocol specification is
supposed to be read by programmers who would know what a Unix-
style file descriptor is.  In fact, if you go back to rfc2543, it
actually had actual *C code* for demonstrating how to write a forking
proxy (which I must say was great for understanding forking
mechanics when I wrote my first forking proxy back in 1998.)  Other
RFCs also have code and domain-specific nomenclature (see for example
drafts and RFCs in PKIX, many of which have ASN, BER, DER and other
encodings and cryptographic language pertinent to and rooted in that
domain.)

> worried about the next 200 readers.)

OK; I think it may be good to separate the notion of persistent
connection (as suggested by Hadriel) and connection reuse.  The
former is when a client uses the same connection to send multiple
requests in the downstream direction, and the latter is when the
downstream entity can use the same connection to send new requests
upstream.  I will add this notion in the revision.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 16 Nov 2007 14:48:15 -0600

Hadriel Kaplan wrote:
>> It's using the same word for both, which requires very close 
>> reading to figure out which concept is being talked about at which
>>  time.  (I'm not claiming that *you* don't keep the two ideas 
>> straight, but I'm worried about the next 200 readers.)
> 
> Indeed, I had the exact same confusion and I'm worried about the next
>  199 too.  :)  I would call it "persistent connection", a la HTTP.

OK -- that is a good suggestion; quoting from my last response
to Dale:

> With regards to TCP "persistent connection", where you mean the 
> client can reuse the same TCP connection for requests going to the 
> same server, is that really necessary to put in a standard?  I mean 
> it was always allowed, no?  I guess it's good to make it explicit, 
> but I'm not sure how one knows when it's the right thing to do or 
> not.

The subtle difference here -- unlike in HTTP -- is that there
are requests coming towards the client from the server.  In HTTP,
the communication is one-way: the browser opens a connection to
the server and sends requests over that connection and can treat
that as a persistent connection for subsequent requests.  AFAIK,
in HTTP the server does not send a *request* towards the client
(the browser) over that same connection.

> I agree there are clients creating new TCP connections per SIP 
> session, and tearing down old ones, and that's very bad in some 
> situations, but it's essentially a local policy decision.  A client 
> is free to open and close TCP connections at will.  You can't make it
> keep one open forever. And there is nothing that the signaling is
> doing about it to help in this draft.

Agreed.

> Like for example if the server side stuck something in
> the response to indicate "you may keep this connection open and send 
> any future requests to me over it if you can". (i.e., the 
> Connection/Keep-Alive header model as in HTTP)

connect-reuse is arguing for this to be the default behavior in
SIP.  Except of course, requests in the backwards direction should
not use a connection that has not bom (8.11.7p1+Sun/8.12.11) with ESMTP id
	lAGKmFj22956; Fri, 16 Nov 2007 14:48:20 -0600 (CST)
Date: Fri, 16 Nov 2007 14:48:15 -0600
From: "Vijay K. Gurbani" <[email-masked]>
Organization: Bell Labs Security Technology Research Group
To: [email-masked]
Subject: Re: [Sip] WGLC: draft-ietf-sip-connect-reuse-08.txt
Cc: IETF SIP List <[email-masked]>

Hadriel Kaplan wrote:
>> It's using the same word for both, which requires very close 
>> reading to figure out which concept is being talked about at which
>>  time.  (I'm not claiming that *you* don't keep the two ideas 
>> straight, but I'm worried about the next 200 readers.)
> 
> Indeed, I had the exact same confusion and I'm worried about the next
>  199 too.  :)  I would call it "persistent connection", a la HTTP.

OK -- that is a good suggestion; quoting from my last response
to Dale:

> With regards to TCP "persistent connection", where you mean the 
> client can reuse the same TCP connection for requests going to the 
> same server, is that really necessary to put in a standard?  I mean 
> it was always allowed, no?  I guess it's good to make it explicit, 
> but I'm not sure how one knows when it's the right thing to do or 
> not.

The subtle difference here -- unlike in HTTP -- is that there
are requests coming towards the client from the server.  In HTTP,
the communication is one-way: the browser opens a connection to
the server and sends requests over that connection and can treat
that as a persistent connection for subsequent requests.  AFAIK,
in HTTP the server does not send a *request* towards the client
(the browser) over that same connection.

> I agree there are clients creating new TCP connections per SIP 
> session, and tearing down old ones, and that's very bad in some 
> situations, but it's essentially a local policy decision.  A client 
> is free to open and close TCP connections at will.  You can't make it
> keep one open forever. And there is nothing that the signaling is
> doing about it to help in this draft.

Agreed.

> Like for example if the server side stuck something in
> the response to indicate "you may keep this connection open and send 
> any future requests to me over it if you can". (i.e., the 
> Connection/Keep-Alive header model as in HTTP)

connect-reuse is arguing for this to be the default behavior in
SIP.  Except of course, requests in the backwards direction should
not use a connection that has not been authenticated through TLS.

> Some vendors restrict how many simultaneous connections they'll allow
> from the same client, for security reasons, so are you thinking 
> along those lines?

Would that not in fact argue for persistent connections anyway?

Thanks,

- vijay

een authenticated through TLS.

> Some vendors restrict how many simultaneous connections they'll allow
> from the same client, for security reasons, so are you thinking 
> along those lines?

Would that not in fact argue for persistent connections anyway?

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 16 Nov 2007 17:04:43 -0600

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

Hadriel: Thanks for your in-depth WGLC review and feedback.
More inline.

> 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.

S5.2 cautions against reusing TCP connections in the same manner
as TLS (i.e., a single connection used to send requests in
both directions.)  The reason this was added was to warn implementors
not to do so (for reasons in S9.3)  When I inherited connect-reuse
(-04), it talked mostly about TLS connection reuse and did not
mention TCP connection reuse at all.  Thus, I added some discussion
on TCP and SCTP connection reuse into the draft.

Based on the same feedback by Dale as well, I will wordsmith S5.2
to point to rfc3261.

> 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?

You are absolutely right.  In that example I just assumed that the
DNS SRV for P2 pointed to the default port, 5061.  The example
is not implying that DNS SRV only yielded P2's IP address and
that P1 used the default port (5061) for TLS.  I will make that
a bit more clear maybe using the non-defaulted TLS port number.

> 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)

True; although when we (i.e., the co-authors) had initially fleshed
out the session hijacking scenario, we were thinking more about a user
agent and not a proxy per se (note the alias parameter can be used
between any neighboring user agents, i.e., UAC->Proxy, Proxy->Proxy,
Proxy->UAS, and UAC->UAS.)  I can drill down and talk about the
perils of a UAC->Proxy TCP connection reuse (i.e., connection
hijacking) and then talk about the perils of an un-authenticated
Proxy->Proxy TCP connection reuse as you outline below ...

> 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.

... would that be an acceptable compromise?

> 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.

OK; good point.  I will downgrade the strength to a SHOULD.

> 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.

The tact the draft takes is not to accept requests from the far
end unless the far end has been authenticated through TLS.  So I
would find it rather disconcerting if the draft allowed an entity
to accept a request over an unauthenticated connection.

> 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).

OK; good point.  I will make this more explicit.

> 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.

Yes ... good catch.  I will reword.

> 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.

Yes, you are right.  Dale also pointed this out when he said in his
review that:

    Examples tend to discuss multiple user agents and proxies,
    when the entirety of the mechanism can be described by
    considering only the two SIP agents at the ends of the
    connection.

I think that approaching it as Dale has stated it -- two SIP agents
at the ends of the connection -- is the right way to go.  I will
change the text to reflect this in the new revision.

> 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".

Yes.

> 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)

I will fix this -- the double period is an easy fix.  Regarding
the first comment in the above paragraph, S5.2 and S8.1 agree insofar
as saying that TCP transports do not require an "alias" parameter.
However since S5 is informative only, I did not put in any normative
language.

Thanks for your review, Hadriel.

- vijay

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Nov 2007 21:10:51 -0500

> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: Friday, November 16, 2007 3:48 PM
>

Right, but that's why I say it's the same thing as TCP persistent connections in this draft.  You're not allowing upstream requests over TCP, only over TLS.  You're saying keep the TCP connection from the client to the server open, and send subsequent requests over it in the downstream direction (client->server).  Requests going the other direction are sent over a TCP client->server connection from the other side.  In that way it's exactly like HTTP/1.1.

> SIP.

Oh. Ok.

> Would that not in fact argue for persistent connections anyway?

Sure, but it doesn't solve it.  Persistent connections were always possible, so even if this new draft says to do it by default, the server has no way to know it is or isn't being done, and the client has no way to be told to do it. (not that I'm advocating that be done mind you)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Nov 2007 22:20:29 -0500

> Sent: Friday, November 16, 2007 6:05 PM
> To: Hadriel Kaplan
> Cc: IETF SIP List; Rohan Mahy; Brett Tate

I wouldn't. :)  It is no more "authenticated" than if the remote end opened a connection using an ephemeral port to the local host's listen port.  The local host client knows little about the validity of the remote end.  Actually, the client knows slightly more about the validity of a connection it opened to the far-end than the other way-around, especially if it did single-sided TLS to the far-end, so in that sense it makes more sense to accept requests over its client socket than over the listen port.  It just doesn't make much sense for the remote end to send them over it, unless it can authenticate (e.g., using digest).  And that's the rub.  Today certain types of devices fix NAT traversal for SIP/TCP or SIP/TLS without needing the client to do sip-outbound, so long as the client can accept requests over its persistent connection, because they can authenticate the client.  It's worked so far, anyway.  But this new MUST would break it.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Nov 2007 13:12:15 -0500

> ... would that be an acceptable compromise?

Sure.

BTW, out of curiosity, I thought at some point in the past there was an email saying that for UA's, sip-outbound would be the only draft for explicit connect-reuse behavior.  So that this draft was really for proxies, not UA's.  Not true? (not that such use would be enforced in any way, just that the focus had changed)

-hadriel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 19 Nov 2007 12:22:30 -0600

Hadriel Kaplan wrote:
>> The subtle difference here -- unlike in HTTP -- is that there are
>> requests coming towards the client from the server.  In HTTP, the
[...]
> Right, but that's why I say it's the same thing as TCP persistent
> connections in this draft.  You're not allowing upstream requests
> over TCP, only over TLS.  You're saying keep the TCP connection from
> the client to the server open, and send subsequent requests over it
> in the downstream direction (client->server).  Requests going the
> other direction are sent over a TCP client->server connection from
> the other side.  In that way it's exactly like HTTP/1.1.

OK; we are in vehement agreement, then.

> Sure, but it doesn't solve it.  Persistent connections were always
> possible, so even if this new draft says to do it by default, the
> server has no way to know it is or isn't being done, and the client
> has no way to be told to do it. (not that I'm advocating that be done
> mind you)

It is true what you write above; i.e., in SIP, the server has no way
of knowing whether the client is using persistent connections or not,
and the client has no way of signaling its intent (unlike in HTTP,
where the signaling makes this clear.)

However, as an implementor, there is some ambiguity in rfc3261 about
how long to keep connections open.  S18 is where this information
is concentrated, and it basically recommends implementations keep
connections open for at least (T1*64)s.  And I have observed wide
variability around this: some implementations close connections
after (T1*64)s, some keep them open for longer, while others even
open up a new TCP connection to send a response (and then promptly
close it.)  So, one aspect connect-reuse was trying to establish
was to establish a default behavior so that the connection stays
open for as long as possible; certainly beyond (64*T1)s, and in
fact, as long as the resources on a machine allow that connection
to remain open.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 19 Nov 2007 12:22:50 -0600

>> ... would that be an acceptable compromise?

OK; good.

> BTW, out of curiosity, I thought at some point in the past there was
> an email saying that for UA's, sip-outbound would be the only draft
> for explicit connect-reuse behavior.  So that this draft was really
> for proxies, not UA's.  Not true? (not that such use would be
> enforced in any way, just that the focus had changed)

True, after outbound came into the picture, connect-reuse has
been relegated mostly to proxies.  Although, as Dale accurately
observed, the draft tends "to discuss multiple user agents and proxies,
when the entirety of the mechanism can be described by considering
only the two SIP agents at the ends of the connection."

We could nail a line in the sand and make this more concrete (i.e.,
use between proxies only.)  Or we could take a middle road and allow
implementors who have reflective connectivity between a UA and a
(proxy) server use connect-reuse.  So far, the draft has been taking
the middle road.

Thoughts?

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 19 Nov 2007 12:22:40 -0600

Hadriel Kaplan wrote:
> I wouldn't. :)  It is no more "authenticated" than if the remote end
> opened a connection using an ephemeral port to the local host's
> listen port.  The local host client knows little about the validity
> of the remote end.  Actually, the client knows slightly more about
> the validity of a connection it opened to the far-end than the other
> way-around, especially if it did single-sided TLS to the far-end, so
> in that sense it makes more sense to accept requests over its client
> socket than over the listen port.  It just doesn't make much sense
> for the remote end to send them over it, unless it can authenticate
> (e.g., using digest).  And that's the rub.  Today certain types of
> devices fix NAT traversal for SIP/TCP or SIP/TLS without needing the
> client to do sip-outbound, so long as the client can accept requests
> over its persistent connection, because they can authenticate the
> client.  It's worked so far, anyway.  But this new MUST would break
> it.

Hadriel: So essentially you are arguing for one of the following
positions (assume A makes an active TCP connection to B to send a
request downstream):

   1) Allow B to send requests upstream (to A) as long as A can
    authenticate B, possibly using HTTP Digest (although how we
    will do so if A and B are proxies is an open question.)
   2) Downgrade the strength of S8.1 to something like the following:
    OLD:
     It MUST only accept responses over this connection and MUST NOT
     accept any requests over this connection.
    NEW:
     It accepts responses over this connection, but SHOULD NOT accept
     any requests.

Is that an accurate representation of your concern?  Given that the
problem of using HTTP Digest between proxies is a complete new
can of worms, the downgrade option seems more attractive.  Would be
nice to hear other opinions.

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Nov 2007 15:25:22 -0500

>     It accepts responses over this connection, but SHOULD NOT accept

The above both seem like nonsense to me. Neither deals with the 
essential issue that B has no way of verifying that it is talking to A.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Nov 2007 10:05:02 -0500

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, November 19, 2007 3:25 PM
> To: Vijay K. Gurbani
> Cc: Hadriel Kaplan; IETF SIP List; Rohan Mahy; Brett Tate

No, B does have a way of verifying it's talking to A.  B can digest challenge A for the requests it got from A over that same connection previously.  As written in the draft, B has no way to verify it's talking to A when it creates a new TCP connection to A, other than to believe the TCP listener is A and SYN/ACK exchange is happening with A.  But we don't have to say anything about this.  Just remove the MUST statement in the draft that A must not accept requests from B over a TCP or single-sided TLS connection created by A to B.  You already say B must not reuse the connection to A because it's not authenticated.  Leave it at that.

I am not arguing this just for the sake of argument.  Today this property of reusing the connection from A to B for requests back to A is already deployed, and is essential for NAT traversal to work.  It works, and is as secure as could be under the circumstances.  A creates a TCP or client-TLS connection to B.  A sends a request, B challenges it, A answers the challenge.  B can then knowingly send requests over the connection to A, and there's no reason for A to reject them.  This is in fact the premise for sip-outbound as well.

-hadriel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 20 Nov 2007 09:25:38 -0600

Trying to drill down to the mechanics of how this will work so the
draft can be updated...

Hadriel Kaplan wrote:
> No, B does have a way of verifying it's talking to A.  B can digest
> challenge A for the requests it got from A over that same connection
> previously.  

What if A and B are proxies?  Digest will not work in that case.

> As written in the draft, B has no way to verify it's
> talking to A when it creates a new TCP connection to A, other than to
> believe the TCP listener is A and SYN/ACK exchange is happening with
> A.  

Well, insofar if you trust DNS (yes, I know the fallacy of that
assumption, but ...), B has some  semblance that it is talking to A
since it got A's routing address from a DNS query.

> But we don't have to say anything about this.  Just remove the
> MUST statement in the draft that A must not accept requests from B
> over a TCP or single-sided TLS connection created by A to B.  You
> already say B must not reuse the connection to A because it's not
> authenticated.  Leave it at that.

Remove the statement, or soften the normative tone to a SHOULD?

> I am not arguing this just for the sake of argument.  Today this
> property of reusing the connection from A to B for requests back to A
> is already deployed, and is essential for NAT traversal to work.  It
> works, and is as secure as could be under the circumstances.  A
> creates a TCP or client-TLS connection to B.  A sends a request, B
> challenges it, A answers the challenge.  B can then knowingly send
> requests over the connection to A, and there's no reason for A to
> reject them.

Problem is that this challenge-response mode in SIP is defined
in HTTP Digest, and that is applicable only between a proxy/registrar
and a UA.  What happens if A and B are proxies?  Or am I missing
something?

Thanks,

- vijay

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Nov 2007 14:18:46 -0500

> Sent: Tuesday, November 20, 2007 10:26 AM
> To: Hadriel Kaplan
> Cc: Paul Kyzivat; IETF SIP List; Rohan Mahy; Brett Tate

True enough. (well... actually some proxies are digest challenged, but they essentially act as UA's for that, and obviously it requires a shared secret)
I was just responding to Paul when he said B has no way to authenticate A.  And B may well have local configuration which tells it that A is who it thinks it is.  For example this is sometimes the case for SIP-PBX connections to providers.  The PBX is essentially a proxy (ie, "Proxy A"), and is sometimes behind a firewall, and the TCP connection from it to the provider's proxy B needs to be reused for requests to the Enterprise due to that firewall.  Certain machinations occur to keep that TCP connection up and re-open it if it fails, but essentially the validity of using it for requests to the Enterprise is provisioned or somehow known by Proxy B.  I'm not asking any of that be specified, defined, etc.  I'm just using a real-world example, to say there are cases where B knows (or thinks it knows) who Proxy A is.

> and a UA.  What happens if A and B are proxies?  Or am I missing

I think the disconnect is you're trying to say proxy A should police the behavior of proxy B?  Proxy B may or may not have a legitimate reason for sending a request to proxy A on A's client TCP/TLS connection.  The draft should and does say B shouldn't do this, but of course that can always be overridden by B's local policy (ie, it may know better).  If it has such a policy, there is really no reason A shouldn't allow it.  Even if it DOESN'T have such a policy, there is really no reason A shouldn't allow it.  There is nothing damaging to A, nor A's domain, about accepting a request over that connection vs. its listen socket.

It's B's responsibility and fault if it sends requests to the wrong agent.  It's not A's role or fault for accepting them.  It's up to proxy B to figure out who/where proxy A is.  It's not up to proxy A to second-guess what B thinks it knows.  Proxy A knows who Proxy A is.

-hadriel
p.s., sorry for sticking on this point, it's just that when we get into debates with other vendors over interop issues in the field, RFCs are the tie-breakers; and these seemingly innocuous statements in RFCs often come back to bite us. :(

---

From: [email-masked]
Date: Tue, 20 Nov 2007 14:53:48 -0500

It's clear that connection-reuse can be done between a UA and a proxy
(or two UA's for that matter).  It doesn't solve the problem that
outbound solves, namely what if connections can only be opened in one
direction.  (connection-reuse implicitly assumes that whoever wants to
send a request first can open a connection.)  What we need to make
sure is that the two mechanisms don't interfere with each other.  This
probably isn't hard, no more than saying "if you're using outbound to
communicate with a SIP agent, don't use connection-use to talk to that
agent".

Dale

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 20 Nov 2007 16:21:42 -0600

Hadriel Kaplan wrote:
> True enough. (well... actually some proxies are digest challenged,
> but they essentially act as UA's for that, and obviously it requires
> a shared secret) I was just responding to Paul when he said B has no
> way to authenticate A.
[...]
> I think the disconnect is you're trying to say proxy A should police
> the behavior of proxy B?  Proxy B may or may not have a legitimate
> reason for sending a request to proxy A on A's client TCP/TLS
> connection.  

Hadriel: The bottom line of your reasoning boils down to this:

If A opens up a TCP connection to B, and it has some policy such
that it considers B to be trusted, it MAY insert an alias parameter
in the topmost Via of that request.  This will cause B to send
requests in the backwards direction over that connection.
Exactly what this policy is will be left up to each service
provider and implementation.

The draft can adequately warn implementations not to do so over
TCP due to various security reasons documented elsewhere in the
draft.  The normative strength of reusing a TCP connection in
this manner could be left as a SHOULD, with strong incentives
to perform connection reuse only over TLS.

Would this be a working solution that will strike a middle-
ground?  Is this agreeable to everyone else (Paul? others?)

> sorry for sticking on this point, it's just that when
> we get into debates with other vendors over interop issues in the
> field, RFCs are the tie-breakers; and these seemingly innocuous
> statements in RFCs often come back to bite us. :(

Funny -- so you have also been doing the frantic "RFC3261-dance-to-
support-my-argument (TM)" ;-)

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 20 Nov 2007 16:21:50 -0600

> communicate with a SIP agent, don't use connection-use to talk to that

Agreed -- sounds good.  A version of such a statement is already
given in S2:

    2. Applicability Statement

    The applicability of the mechanism described in this document is for
    two adjacent SIP entities to reuse connections when they are agnostic
    about the direction of the connection, i.e., either end can initiate
    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 [9].

I can reword this to make the outbound part more explicit; something
like:

    2. Applicability Statement

    The applicability of the mechanism described in this document is for
    two adjacent SIP entities to reuse connections when they are agnostic
    about the direction of the connection, i.e., either end can initiate
    the connection.  If connections can only be opened in one direction,
    perhaps due to the existence of firewalls and Network Address
    Translators (NATs), then the mechanism described by Jennings and
    Mahy [9] MUST be used instead.

Okay?

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Nov 2007 18:04:29 -0500

Inline.

Hadriel Kaplan wrote:
> No, B does have a way of verifying it's talking to A. 
> B can digest challenge A for the requests it got from A
> over that same connection previously. 

In general a digest challenge from B to A can't be correlated directly 
to the address of A. So a successful response to the challenge won't 
help with future reverse routing.

What is the digest challenging?

Lets take a case. Assume we have sip:[email-masked] calling 
sip:[email-masked]. But the call goes first to sip:edge.atlanta.com 
(based on some outbound "proxy" configured for alice) and then to 
sip:edge.biloxy.com (based on SRV lookup), and then to sip:[email-masked].

And lets just consider connection reuse between edge.atlanta.com and 
edge.biloxi.com. The connection is established in that direction. 
edge.biloxi.com *thinks* the name of the previous hop is 
edge.atlanta.com because of the Via header. But what digest challenge 
can edge.biloxi.com do to verify that the prior hop is who it thinks it is?

> As written in the draft,
> B has no way to verify it's talking to A when it creates a new
> TCP connection to A, other than to believe the TCP listener is A
> and SYN/ACK exchange is happening with A. 

The original connection was from A to B, and A had no better way to 
verify that it was talking to B.

> But we don't have to
> say anything about this.  Just remove the MUST statement in the
> draft that A must not accept requests from B over a TCP or
> single-sided TLS connection created by A to B.  You already say B
> must not reuse the connection to A because it's not authenticated. 
> Leave it at that.

I will agree that this isn't a concern of A's. It is B that has the 
concern, and lacks knowledge to reuse the connection. So it is B that we 
should be giving MUST NOT or SHOULD NOT instructions to.

I would be ok with saying that B MUST NOT reuse this connection for 
requests to the supposed party at the other end UNLESS it has some way 
of verifying the identity of that party to the same level of assurance 
as it would have by doing the DNS lookup and establishing its own 
connection. For instance, if a DNS lookup resolved to the same address 
and port as the source port of the inbound connection then that ought be 
be good enough.

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Nov 2007 18:31:44 -0500

> Sent: Tuesday, November 20, 2007 6:04 PM
> To: Hadriel Kaplan
> Cc: Vijay K. Gurbani; IETF SIP List; Rohan Mahy; Brett Tate
> [snip]

As I said in another email, I was referring to digest challenge for endpoints, not proxies.
People do digest-challenge proxies, but they do so in a weird way - for example they digest challenge a Register from the proxy acting as a UA, where the proxy has a specific AoR that represents its "trunk". (this is basically the SIP-Forum's SIP-Connect optional PBX registration model - it's not well defined, and not clean from a SIP perspective)

> and port as the source port of the inbound connection then that ought be

Awesome - that's all I'm saying as well.  B must not reuse the connection unless it knows better.  If it sends the request to A over A's client connection, there's no reason to mandate A not accept it.  A has nothing to fear, only B does.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Nov 2007 19:22:29 -0500

> People do digest-challenge proxies, but they do so in a weird way - for example they digest challenge a Register from the proxy acting as a UA, where the proxy has a specific AoR that represents it…

Even with endpoints its not good enough in general.

If a request is From sip:[email-masked] and you successfully digest 
challenge that, does it mean that you can send a request to 
sip:[email-masked] on the same connection? Not unless you can 
actually tie the digest credentials to <sip:atlanta.com>.

But I guess you were only using digest as an example, while you actually 
intend to use some other technique.

> Awesome - that's all I'm saying as well.  B must not reuse the connection unless it knows better.  If it sends the request to A over A's client connection, there's no reason to mandate A not accept…

Well, I really wasn't trying to "make your day". :-)

I fear leaving it that loose without at least some added words of 
wisdom. Perhaps some statements about typical means of decision that are 
not sufficient. (E.g. a successfully digest challenged registration of 
sip:[email-masked] does not mean that the connection can be reused 
for anything addressed to sip:atlanta.com.

We have a lot of history of people taking carefully phrased things like 
this and using them to justify a lot of incorrect behavior. We don't 
want this to be misconstrued.

	Thanks,
	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 21 Nov 2007 16:22:48 -0600

> want this to be misconstrued.

Paul, Hadriel: So ... where do we stand on this?  It appears that
Digest challenge for proxies is a non-starter.  Yesterday, I
had suggested something along these lines:

This, of course, means that there is connection reuse in TCP
as well (i.e., using one TCP stream), but is not encouraged by
the draft, and implementations doing so will have adequately
weighed in the associated risks before doing so.

Would this be a working solution that will strike a middle-
ground?  Is this agreeable?

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Nov 2007 18:29:38 -0500

I think much less should be said.

Don't say that A must reject requests sent to it over the connection. 
But also don't specify, or even imply, a mechanism by which B might 
decide it is ok to send requests on this connection. And I think the 
Alias is bad because it implies such a mechanism.

Vijay K. Gurbani wrote:
> Paul Kyzivat wrote:
>> We have a lot of history of people taking carefully phrased things 
>> like this and using them to justify a lot of incorrect behavior. We 
>> don't want this to be misconstrued.
> 

As Hadriel pointed out, there is no issue of trust on the part of A. 
(Were A to get a request over this connection that was addressed to A it 
would have no more reason to distrust it than if it got the same request 
over some other connection.) So the above is a sort of red herring.

The issue of trust is with B. A passing an alias parameter doesn't give 
B any reason to believe the connection is really with A.

>   to perform connection reuse only over TLS.

The above seems ok to me.

> weighed in the associated risks before doing so.

I can almost buy not *banning* it. But that is not the same as actually 
having it in the draft.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 21 Nov 2007 22:08:05 -0600

Paul Kyzivat wrote:
> decide it is ok to send requests on this connection.

Any way you cut, slice, and dice this thing, TCP connection reuse
in the backwards direction is bad.  Note that it does not work with
virtual servers at all.

Unfortunately, people are using it and as such something ought to
be said about it in the draft.  I agree that as the less said, the
better.  I also agree that putting the "alias" parameter in the
Via request for TCP.

Going back to our scenario of A opening a connection to B, it
probably suffices to massage the text you proposed in an earlier
email of this thread:

    B MUST NOT reuse this connection for requests to the
    supposed party at the other end UNLESS it has some way
    of verifying the identity of that party to the same level
    of assurance as it would have by doing the DNS lookup and
    establishing its own connection. For instance, if a DNS
    lookup resolved to the same address and port as the source
    port of the inbound connection then that ought be be good
    enough.

This still does not solve the problem of reusing TCP connections
for virtual servers; i.e., B does not know that that A's physical
IP address is being used by multiple virtual domains.  Again, I
can just point this out for the TCP and SCTP transport in
the virtual server section more emphatically and leave it at that.

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Nov 2007 11:20:39 -0500

> better.  I also agree that putting the "alias" parameter in the

There seems to be something wrong with the last sentence. Did you forget 
a word or two?

>    port of the inbound connection then that ought be be good

I was thinking about that too. That "for instance" *seems* reasonable to 
me, but I would like to hear what others think.

> IP address is being used by multiple virtual domains. 

I don't understand what point you are making here.

	Thanks,
	Paul

> Again, I

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 23 Nov 2007 14:09:47 -0600

> There seems to be something wrong with the last sentence. Did you forget 

Yes, sorry; I meant to say that "I also agree that putting the "alias"
parameter in the Via request for TCP is not a good idea."

> I don't understand what point you are making here.

Consider named-based virtual hosting in SIP, where the same IP
address supports multiple domains.  red.com and blue.com are hosted
on a physical server that uses one IP address.  Now, when red.com
makes a TCP connection to another domain -- example.com -- then
example.com may want to use this TCP connection to send requests
to blue.com (because blue.com's IP address matches red.com's).

Same problem we had in TLS, except the way we solved it in TLS
was to associate the identity picked up from the certificate with
the connection.

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Nov 2007 17:20:04 -0500

Interestingly, doing the DNS lookup for blue.com, and recognizing that 
you already have a connection from that address would work in this case.

	Paul

Vijay K. Gurbani wrote:
>> There seems to be something wrong with the last sentence. Did you 
>> forget a word or two?
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sun, 25 Nov 2007 18:11:58 -0600

> you already have a connection from that address would work in this case.

Precisely, and therein lies the problem, right?  example.com
is using one connection to the virtual server to deliver requests
destined for another domain on the same virtual server.

Or are we talking past each other?

- vijay

---

From: [email-masked]
Date: Sun, 25 Nov 2007 20:58:00 -0500

After thinking about this some more, I'll retract my objection.  In
principle, I think the problem still stands, but this case is simple
enough that no trouble can result.

Do note:  You introduce the table in section 5, which is marked
non-normative.  But you refer to the table 16 times in section 8,
which is marked normative, and furthermore you don't re-introduce the
table or its behavior.  Which, unless I've overlooked something again,
means that the normative section 8 contains a prerequisite reference
to the non-normative section 5.  I think you're going to have to
adjust that.

I doubt harm can come from it, but I don't see the Posix programming
model as being one of the background domains for understanding SIP.
Suppose, for example, that one's SIP stack was written in Java...

Dale

---

From: [email-masked]
Date: Sun, 25 Nov 2007 21:08:33 -0500

Why would it be a problem?  By hypothesis, that port on that address
must be able to receive and process messages for both domains.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 25 Nov 2007 21:26:34 -0500

I think you're talking past each other.  Your original statement did not specify their listen ports would be different.  If they're not different, ie if both domains end up pointing to the same IP+port on the server, then they are the same server, which just happens to be servicing multiple domains, and sending to the same connection is fine.  If they're the same IP but different ports, such that SRV resolves example.com to port 5060 and blue.com to 5070, for example, then you shouldn't send to both domains on the same connection - because they may well be two different processes, and example.com could lie and take over blue.com's requests.

-hadriel

> Sent: Sunday, November 25, 2007 7:12 PM
> To: Paul Kyzivat
> Cc: IETF SIP List

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 25 Nov 2007 22:08:16 -0500

> Or are we talking past each other?

Perhaps. I guess it depends on your assumptions about how these things 
are demultiplexed. If at the connection level then it is a problem. If 
at the message level then it isn't a problem.

	Paul

---

From: [email-masked]
Date: Sun, 25 Nov 2007 23:03:54 -0500

From: Paul Kyzivat <[email-masked]>

My impression has always been that demultiplexing is done at the
message level.  It seems implicit in the RFC 3263 processes that once
one has resolved the address/port that any connection (with the right
protocol) to that address/port is OK.  In any case, the recipient
would have to see the first message before committing to service only
one domain, as there isn't any other way to tell which domain a new
connection is for.

Which has a derivative problem when setting up TLS that the recipient
doesn't know which domain it needs to provide a certificate for when
the connection is established.  IIRC, someone has proposed a solution
where the recipient presents a certificate that specifies all of the
domains it is authoritative for.

Dale

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 26 Nov 2007 13:43:59 -0600

Hadriel Kaplan wrote:
> I think you're talking past each other.  Your original statement did
>  not specify their listen ports would be different.

Yes, Hadriel is accurate in pointing that out.

> If they're not different, ie if both domains end up pointing to the 
> same IP+port on the server, then they are the same server, which just
> happens to be servicing multiple domains, and sending to the same 
> connection is fine.

...but fraught with peril, though.  Technically this is feasible,
because there is enough information in the signaling to allow
routing to the right virtual server (I think.)  HTTP uses the Host
header to allow the virtual server to distinguish different
domains.  The SIP equivalent is the domain name in the R-URI or
topmost Route header; the domain in one of these URIs should point
to the right virtual domain.

Now, whether we should be actively encouraging this over TCP is
another question.  Note that over TLS, we do not.  That is,
if red.com opens a TLS connection to example.com, then red.com's
identity (sip:red.com) is saved in the alias table.  Thus,
when example.com sends a request to blue.com, even though
rfc3263 resolution will result in the same IP+port, the earlier
connection will not be reused because the identity does not
match (i.e., sip:red.com != sip:blue.com).

> If they're the same IP but different ports, such that SRV resolves
> example.com to port 5060 and blue.com to 5070, for example, then you
   ^^^^^^^^^^^ red.com
> shouldn't send to both domains on the same connection - because they
> may well be two different processes, and example.com could lie and
                                            ^^^^^^^^^^^ red.com
> take over blue.com's requests.

Right.  That is what I was worried about.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 26 Nov 2007 13:44:20 -0600

> to the non-normative section 5.  I think you're going to have to

OK; that is reasonable.

> Suppose, for example, that one's SIP stack was written in Java...

Why, convert it to C/C++, of course ;-)  But seriously, I will
add some text equating the alias descriptor to connection objects
found in other languages.

Thanks, Dale.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 26 Nov 2007 13:44:26 -0600

> domains it is authoritative for.

With the TLS extended hello (rfc3546) this is no longer a problem.
In an extended hello, the client can include the "server_name"
extension to allow the server to present the right certificate.

- vijay

---

From: [email-masked]
Date: Mon, 26 Nov 2007 23:53:24 -0500

...but fraught with peril, though.  Technically this is feasible,
   because there is enough information in the signaling to allow
   routing to the right virtual server (I think.)

Actually, in SIP there isn't peril, because SIP is carefully designed
so that the destination is coded absolutely in the SIP request; no
contextual information is needed (in the usual cases) to get the
message to its destination.

Dale