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