Subject: RE: [MMUSIC] Re: Question on sdp-new

From: "Elwell, John" <[email-masked]>
Date: Thu, 13 Oct 2005 20:06:41 +0100

Dan,

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: 13 October 2005 19:47
> To: 'Colin Perkins'
> Cc: Elwell, John; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: [MMUSIC] Re: Question on sdp-new
> 
> >> What do you mean by 'interoperate'?  My read of -avt-rtcp- 
> >> feedback-11 is
> >> that both sides of an offer/answer would need to understand 
> >> the RTP/AVPF profile.
> > 
> > See section 5 of draft-ietf-avt-rtcp-feedback-11.txt
> 
> Yes, I read that before responding.  But I'm still failing to 
> grasp how an
> AVPF-unaware endpoint would do anything but reject an m= line 
> containing
> AVPF.  Specifically, if my offer says:
> 
>   ...
>   m=audio 49170 RTP/AVPF 0
>   ...
> 
> and the answerer only understands RTP/AVP, the answer will 
> contain only "m="
> for that media line (that is, that media line is rejected).  
> I'll have to
> send another offer with RTP/AVP, under the assumption the 
> reason it was
> rejected was AVPF.  This gets really messy
> 
> It's the same problem of sending RTP/SAVP -- the answer won't 
> understand
> "SAVP" and will reject that media line.
> 
> > > Overall I'm very worried about this profile explosion especially
> > > when we introduce non-UDP transports for RTP.
> > 
> > Agreed. This is certainly a problem (although much of the 
> > difficultly comes due to the limitations of SDP, rather than 
> > the proliferation of RTP profiles as such).
> 
> We need a heart-to-heart on how to solve that -- SDPnew or 
> other mechanisms,
> such as multipart MIME or clearly defining semantics of port 
> overlaying in
> SDPold (which started this thread).  
> 
> SDPnew will require multipart/alternative unless we want to 
> incur 2x the
> call processing overhead (and associated call setup delays) 
> with introducing
> SDPnew.
[JRE] I do agree this is a general problem that needs solving. I am not sure
whether multipart/alternative is the right solution. At least the way it was
proposed in Cullen's draft, it was a way of dealing with a body that you
cannot interpret. However, we have cases where we can interpret a body
(i.e., we understand SDP in this case), but we don't understand a profile
such as RTP/SAVP or we don't understand an attribute such as a=crypto or
a=key-mgmt. The only solution I have found within SDP itself is to use
multiple m= lines with different ports and rely on the answerer selecting
only one (or if the answerer selects more than one, removing unwanted ones
with a second offer-answer). Not very satisfactory.

John

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 14 Oct 2005 14:47:38 +0100

Paul,

In-line.

John

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 14 October 2005 14:11
> To: Mats Näslund
> Cc: Elwell, John; [email-masked]; [email-masked]; 
> Mark Baugher; [email-masked]; [email-masked]
> Subject: Re: [MMUSIC] Question on sdp-new
> 
> 
> 
> Mats Näslund wrote:
> > Hi,
> > 
> > Jumping in late here, sorry.
> > 
> > Paul Kyzivat wrote:
> > 
> >>
> >>
> >> Elwell, John wrote:
> >>
> >>> Mark,
> >>>
> >>> Thanks, but if I remember correctly, Cullen's document 
> was to do with
> >>> different body types in a SIP message, e.g., S/MIME or 
> MIME versions 
> >>> of the
> >>> same body or SDP and SDPng. I don't think it extended to 
> different 
> >>> options
> >>> within the same body type.
> >>
> >>
> >>
> >> No, it didn't. But the proposal was to have two different 
> SDP bodies, 
> >> one offering RTP and the other offering SRTP. We came to the 
> >> conclusion that two bodies are needed because the SRPT 
> offer/answer 
> >> needs to be protected with S/MIME, and one can probably 
> expect a UA 
> >> that supports SRTP to support S/MIME. But you probably shouldn't 
> >> expect all UAs to support S/MIME.
> > 
> > It seems to me that it is not (only) the SRTP offer that needs to be
> > protected, but rather the combination of the two RTP/SRTP offers. If
> > this is not done, a "man in the middle" simply deletes the SRTP-part
> > (be it protected or not), leaving only plain RTP. This would be
> > a so-called bidding down attack.
> 
> The MiTM attack is considered an unavoidable consequence 
> here, and one 
> that is in some cases acceptable. The general situation is that X is 
> calling Y. X has the capability for a secure media session, 
> but doesn't 
> know if Y does. X would like to have a secured conversation 
> with Y, but 
> if that is not possible, X would prefer an insecure 
> conversation to no 
> conversation.
> 
> Once the session is established, X and Y can tell if it is 
> secure. (The 
> "secure" indicator will light up on the phone.) So X and Y can adjust 
> the contents of their conversation based on the security of 
> the session. 
> (X says: "Y - please call me back from a secure phone".)
> 
> A suficiently powerful MiTM can perhaps prevent a secure 
> connection from 
> ever being formed. But X and Y will be able to figure out 
> that this is 
> happening.
[JRE] Agreed. Also there are steps that can be taken such as SIP Identity.

(snipped)