Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)
draft-ietf-mmusic-sdp4nat-05

This document is connected to STUN and a related document is SIP...should it be Last Called alone or wait for the SIP one?  It was rev'd to make sure it aligned with STUN and is ready for Last Call so that question is the only remaining one.

Gave AD review and got revision, now evaluating.  AD
Review:

This has been held while we sorted out how it was related to STUN and to the related document in SIP...

I would like to IETF LC this at the same time as the SIP draft, which will be ready shortly. 

AD review of sdp4nat:

1. it should reference RFC 3261 instead of 2543

2. Instead of section 3.1, which is hypothetical, it can give a reference to STUN (or a small summary and reference).  STUN is the reason we will put this one through.

3. It should comment on UNSAF considerations

  L. Daigle, "IAB considerations for UNilateral self-address fixing (UNSAF) across network address translation," Internet Draft, Internet Engineering Task Force, Approved Sep 2002 draft-iab-unsaf-considerations-02.txt

One point is exit strategy - there won't be ports to discover anduse and so there won't be a need for the sdp4nat parameter in future.  Keep the UNSAF section small, for a small document.


4. Please let us know if the new attribute has been implemented and tested.  If it is known to have been tolerated well in some production deployments, this would be a good point to make under the Brittleness consideration of UNSAF.  We (Transport)like to comment on implementation experience even for Proposed Standards so any details you can provide are welcome (and of course, it is best for the spec if there has been good testing).


5. The Security Considerations describe some risk but no remedy,which will not pass the current Security reviews.  So I suggest a change as follows, which will be a starting point (the SEC Area folks will probably ask for more when they review it...)

----- Old:
This SDP extension is not believed to introduce any significant security risk to multi-media applications. One could conceive that a malevolent third party would use the extension to redirect the RTCP fraction of an RTP exchange, but this require intercepting and
rewriting the signaling packet carrying the SDP text; if an interceptor can do that, many more attacks are available, including a wholesale change of the addresses and port numbers at which the media will be sent.

----- Add something like:

In order to avoid attacks of this sort, when SDP is used in a signaling packet where it is of the form application/sdp, end-to-end integrity using S/MIME (RFC 3369) is the technical method to be implemented and applied.  This is compatible with SIP (RFC 3261).

State Changes to Pre AD Evaluation                                from Requested                                        by mankin