Re: francois' comments and why RFC4474 not used in the field

On Apr 1, 2009, at 4:40 PM, Dwight, Timothy M (Tim) wrote:

> Dean,
>
> Hadriel has answered most of your questions.  On this point:
>
>>> Alternatively, if the SP's infrastructure is in the public address
>>> space, you typically don't see NAT / SIP ALG or topology hiding or
> media
>>> steering.  You may (often do) still see "border devices" doing
> things
>>> like traffic aggregation and policy based routing.
>>>
>>
>> Do we need SDP editing to allow these functions, or is there
>> a cleaner way to do it?
>
> Sorry I wasn't more clear.  These functions don't involve SDP editing.
> Traffic aggregation (by which I mean to refer to aggregation of SIP
> signaling traffic) is usually done with ROUTE headers or use of the
> 'maddr' URI parameter, or (most often) through re-targetting in the
> border device.  Policy routing is some mechanism internal to the  
> border
> device, that it uses to determine how to modify and to where to  
> forward,
> the SIP message.

Okay. . .

The debate here has been over finding ways to change RFC 474 and/or  
DTLS/SRTP so that the media key fingerprint is preserved, enabling the  
full security of DTLS/SRTP.  Since RFC 4474 signs "the whole SDP", any  
edits done to SDP by a middlebox break the RFC 4474 signature, thereby  
breaking the media key fingerprint protection of RFC 4474 (and thereby  
allowing a MITM on the media). If traffic aggregation and policy based  
routing don't require editing SDP in a proxy, then they don't break  
RFC 4474, and we don't have a problem.

Except we MUST have a problem, because  several folks keep saying we do.

So Cullen et. al. have been pushing us to nail down exactly what the  
problem is (and saying RFC 4474 is broken by SBCs is not an answer; it  
is a symptom).

So what seems to be the problem?

--
Dean


_______________________________________________
Sip mailing list  https://www.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