Re: WGLC: draft-ietf-sip-connect-reuse-08.txt

Hadriel Kaplan wrote:
> 
>> -----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)

Even with endpoints its not good enough in general.

If a request is From sip:aliceatlanta.com and you
successfully digest 
challenge that, does it mean that you can send a request to

sip:albertatlanta.com 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:aliceatlanta.com 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://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

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.

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:

   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.

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