[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Sanity check -- relationship between DTLS-SRTPand Identity
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Matt Lepinski
> Sent: Friday, February 29, 2008 1:03 PM
> To: Elwell, John
> Cc: sip at ietf.org; Dean Willis
> Subject: Re: [Sip] Sanity check -- relationship between
> DTLS-SRTPand Identity
>
> I agree with John that there are two identity-related issues
> related to
> DTLS-SRTP framework.
>
> For each of the two problems (the E.164 problem and the SBC problem),
> the working group needs to decide whether it's better to complete
> DTLS-SRTP framework quickly and add appropriate text
> regarding the lack
> of applicability in certain deployment scenarios; or whether
> it's better
> to delay DTLS-SRTP framework while we work on solving the problem.
>
> Personally, I think that the E.164 problem is going to be
> hard to solve,
> and that it should not hold up DTLS-SRTP framework. (That is, that we
> should release a DTLS-SRTP framework that only works with
> "email-style"
> SIP URIs.) That being said, E.164 numbers aren't going away any time
> soon and so I think RAI should definitely perform work on how
> to obtain
> useful (as least PSTN-grade) identity guarantees for SIP
> requests with
> an E.164 number in the From: field.
We can do PSTN-grade identity assertions of E.164's today already:
just trust your pre-configured SIP trunk to not lie. You set up SIP
trunks to organizations with a contractual or gentleman's agreement
to not lie. You don't even need RFC4474 to do that.
That is exactly as good as the PSTN's identity.
> On the other hand, perhaps the SBC problem is one that we
> should resolve
> before advancing DTLS-SRTP framework. In particular, there
> are at least
> two proposals on the table (I.D-wing-identity-media and
> I.D-fischer-sip-e2e-sec-media) that say "use something other than
> RFC4474 for DTLS-SRTP framework". However, the concern that I have in
> solving this problem is that, in the absence of guidelines for how a
> 'well-behaving' SBC will handle particular headers or SDP
> bodies, it's
> hard to design a protocol that will interoperate well with SBCs.
>
> Note: Obviously, this concern is not DTLS-SRTP-Framework specific and
> given that SBC-issues keep coming up in a variety of working groups,
> perhaps RAI needs to reach consensus that either:
> A) We will not address SBC-related concerns when engineering
> protocols
> (e.g. we advance DTLS-SRTP without solving the SBC problem).
> B) We will seek to design protocols that interoperate with "most"
> existing SBCs at the time the protocol specification is written.
> C) We will seek to design protocols that interoperate with
> "well-behaving" SBCs (i.e. SBCs that adhere to the following set of
> guidelines).
> D) ?????
This is all feeling very much like the history of the IETF's
involvement with NATs and the IETF's involvement with firewalls.
-d
> (A) is ignoring the reality that SBCs aren't going away. (B) is
> difficult in practice because SBC behavior is not always
> well-documented
> and seems to change over time. (C) requires significant work writing
> appropriate guidelines that takes cycles away from (more
> important) RAI
> work. Perhaps someone can suggest a good (D)?
>
> - Matt Lepinski
>
> Elwell, John wrote:
>
> >Dean,
> >
> >The DTLS-SRTP framework is clear that you depend on RFC 4474
> to bind the
> >secure media stream to an identity. There are two issues
> with RFC 4474
> >that have received considerable discussion and have led to a
> long list
> >of I-Ds:
> >- The E.164 problem - not a problem if we use DTLS-SRTP only with
> >email-style SIP URIs, but some people would argue that this is not
> >feasible.
> >- The SBC problem.
> >Both of these are real world problems that aren't going to disappear
> >overnight as soon as networks deploy DTLS-SRTP. Rather,
> DTLS-SRTP will
> >not be deployed because it won't work on existing
> infrastructure. I do
> >want to see DTLS-SRTP completed, but not in a way that is of
> no use to
> >much of the market.
> >
> >John
> >
> >
> >
> >>-----Original Message-----
> >>From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> >>Behalf Of Dean Willis
> >>Sent: 29 February 2008 05:36
> >>To: sip at ietf.org List
> >>Subject: [Sip] Sanity check -- relationship between DTLS-SRTP
> >>and Identity
> >>
> >>
> >>Ok, maybe I'm reading something wrong here.
> >>
> >> From the list conversation, it seems like some people think
> >>there's a
> >>relationship between DTLS-SRTP and SIP Identity, aka RFC 4474.
> >>
> >>Other people think that there's a problem applying RFC 4474
> when we
> >>use phone numbers.
> >>
> >>Some people think we use phone numbers a LOT, maybe almost all the
> >>time, and that therefore we really need to figure out how
> >>this impacts
> >>RFC 4474 and our other concepts of identity.
> >>
> >>This makes it seem to me like maybe we need to get the
> >>identity stuff
> >>nailed down before we commit to a final version of DTLS-SRTP.
> >>Or maybe
> >>the other way around -- we nail down DTLS -SRTP, then figure
> >>out what
> >>we need from Identity to support it, then fix Identity. Or
> maybe we
> >>need to fix them both together.
> >>
> >>Now our AD is telling me that by reading it this way, I'm
> >>unprofessionally evidencing bias in favor of some other
> >>protocol that
> >>may have been discussed prior to DTLS-SRTP (and the name of
> which I
> >>honestly can't remember right now). I find this unlikely,
> >>given that I
> >>don't actually understand any of the protocols and only
> >>parrot what I
> >>read on the mailing list earlier today.
> >>
> >>So let's put it to the working group. Is there a relationship
> >>between
> >>DTLS-SRTP, phone numbers, and identity that needs to be
> figured out?
> >>If so, how much of a problem is this? Do we care?
> >>
> >>--
> >>Dean
> >>
> >>_______________________________________________
> >>Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> >>This list is for NEW development of the core SIP Protocol
> >>Use sip-implementors at cs.columbia.edu for questions on current sip
> >>Use sipping at ietf.org for new developments on the application of sip
> >>
> >>
> >>
> >_______________________________________________
> >Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> >This list is for NEW development of the core SIP Protocol
> >Use sip-implementors at cs.columbia.edu for questions on current sip
> >Use sipping at ietf.org for new developments on the application of sip
> >
> >
> >
>
>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip