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-reuse-08.txt

To remove yourself from the I-D Announcement list, send a
message to 
i-d-announce-requestietf.org with the word unsubscribe in the
body of 
the message. 
You can also visit h
ttps://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/s
hadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailservietf.org.
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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

(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: Internet-Draftsietf.org
[mailto:Internet-Draftsietf.org] 
> Sent: Wednesday, October 17, 2007 1:15 AM
> To: i-d-announceietf.org
> Cc: sipietf.org
> 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 i-d-announce-requestietf.org with the word 
> unsubscribe in the body of the message. 
> You can also visit h
ttps://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/s
hadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailservietf.org.
> 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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

(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:dragealcatel-lucent.com] 
> Sent: Tuesday, October 23, 2007 6:24 PM
> To: sipietf.org
> 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: Internet-Draftsietf.org
[mailto:Internet-Draftsietf.org]
> > Sent: Wednesday, October 17, 2007 1:15 AM
> > To: i-d-announceietf.org
> > Cc: sipietf.org
> > 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 
> > i-d-announce-requestietf.org with the word
unsubscribe in 
> the body of 
> > the message.
> > You can also visit 
> h
ttps://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/s
hadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	mailservietf.org.
> > 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://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol Use 
> sip-implementorscs.columbia.edu for questions on current
sip 
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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
bobchicago.example.org."  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


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

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

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

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

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

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

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


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

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

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

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

-hadriel


> > > -----Original Message-----
> > > From: Internet-Draftsietf.org
[mailto:Internet-Draftsietf.org]
> > > Sent: Wednesday, October 17, 2007 1:15 AM
> > > To: i-d-announceietf.org
> > > Cc: sipietf.org
> > > 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
> > > i-d-announce-requestietf.org with the word
unsubscribe in
> > the body of
> > > the message.
> > > You can also visit
> > h
ttps://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/s
hadow.html or
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > > Internet-Drafts can also be obtained by
e-mail.
> > >
> > > Send a message to:
> > >     mailservietf.org.
> > > 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://ww
w1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP
Protocol Use
> > sip-implementorscs.columbia.edu for
questions on current sip
> > Use sippingietf.org for new developments on the
application of sip
> >
>
>
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivatcisco.com]
> Sent: Monday, November 19, 2007 3:25 PM
> To: Vijay K. Gurbani
> Cc: Hadriel Kaplan; IETF SIP List; Rohan Mahy; Brett
Tate
> Subject: Re: [Sip] WGLC:
draft-ietf-sip-connect-reuse-08.txt
>
>
>
> Vijay K. Gurbani wrote:
> > 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.
>
> 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

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


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vkgalcatel-lucent.com]
> Sent: Tuesday, November 20, 2007 10:26 AM
> To: Hadriel Kaplan
> Cc: Paul Kyzivat; IETF SIP List; Rohan Mahy; Brett
Tate
> Subject: Re: [Sip] WGLC:
draft-ietf-sip-connect-reuse-08.txt
>
> 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.

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.


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

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



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivatcisco.com]
> Sent: Tuesday, November 20, 2007 6:04 PM
> To: Hadriel Kaplan
> Cc: Vijay K. Gurbani; IETF SIP List; Rohan Mahy; Brett
Tate
> Subject: Re: [Sip] WGLC:
draft-ietf-sip-connect-reuse-08.txt
>
> 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.
>
> [snip]
> 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 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)


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

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



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vkgalcatel-lucent.com]
> Sent: Sunday, November 25, 2007 7:12 PM
> To: Paul Kyzivat
> Cc: IETF SIP List
> Subject: Re: [Sip] WGLC:
draft-ietf-sip-connect-reuse-08.txt
>
> Paul Kyzivat wrote:
> > Interestingly, doing the DNS lookup for blue.com,
and recognizing that
> > 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
> --
> 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.al
catel-lucent.com/bell-labs
>
>
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip