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
