Dean,
> 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?
I think first of all that we're suffering from a long email thread that
has been snipped a few times, hence we've lost some of the context.
Previously I said there are 2 basic ways that VoIP interconnections are
designed:
1) media pinned at each network border
2) media not pinned at the borders
The above text refers to case #2. If media is not pinned (by which I
mean "steered" to a specific point of network ingress), the things that
the border elements do don't seem to break RFC 4474. I am happy to hear
that.
So the problem seems isolated to interconnect designs involving pinning
the media.
And the question becomes, why do operators do that? Again speaking only
based on my own experience, the rationale is related to the transit
service provided to the media. If the media is going to be carried (and
in practice prioritized) by the transit operator, that operator will
generally want to measure and/or police its arrival rate. Sometimes
this is per microflow, other times it is applied to the aggregate; that
depends on the SLA. Either way, these (and L3 encapsulation and QoS
marking) are functions provided by the device to which the media is
"steered" by fiddling with the SDP.
I am (in general, operators are) aware that just because a transit
operator touches the signaling does not mean it needs to be or should be
in the media path. But there are possible designs (e.g., a series of
private IP networks) where it may be viewed as desirable. Equally,
there are designs (e.g., a group of operators sharing a common IP
network) where media pinning is unnecessary (*). Ergo both design
approaches exist.
It may be tempting to wish this problem away by "outlawing" interconnect
designs involving pinning the media; but IMHO that would be wishful
thinking.
(*) this is a simplified argument. In practice SDP manipulation may be
required
even in the "multiple operators sharing a common IP network"
scenario; e.g.,
to support Lawful Intercept.
Tim
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implement...@cs.columbia.edu for questions on current sip
Use sipp...@ietf.org for new developments on the application of sip
