Hadriel Kaplan wrote:
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
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)
Even with endpoints its not good enough in general.
If a request is From sip:[EMAIL PROTECTED] and you successfully digest
challenge that, does it mean that you can send a request to
sip:[EMAIL PROTECTED] 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.
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.
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 PROTECTED] 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
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
