Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)
|2003-10-13||05||(System)||Ballot writeup text was added|
|2003-10-13||05||(System)||Last call text was added|
|2003-10-13||05||(System)||Ballot approval text was added|
|2003-10-13||05||Amy Vezza||State Changes to RFC Published from RFC Ed Queue by Amy Vezza|
|2003-06-27||05||(System)||IESG has approved the document|
|2003-06-05||05||Natalia Syracuse||State Changes to RFC Ed Queue from Approved-announcement sent by Syracuse, Natalia|
|2003-06-04||05||Amy Vezza||State Changes to Approved-announcement sent from Approved-announcement to be sent by Vezza, Amy|
|2003-06-02||05||(System)||New version available: draft-ietf-mmusic-sdp4nat-05.txt|
|2003-05-30||05||Michael Lee||State Changes to Approved-announcement to be sent from IESG Evaluation by Lee, Michael|
|2003-05-23||05||Michael Lee||State Changes to IESG Evaluation from Waiting for Writeup by Lee, Michael|
|2003-05-23||05||Jon Peterson||State Changes to Waiting for Writeup from In Last Call :: Revised ID Needed by Peterson, Jon|
|2003-05-21||04||(System)||New version available: draft-ietf-mmusic-sdp4nat-04.txt|
|2003-04-10||05||Jon Peterson||State Changes to In Last Call :: Revised ID Needed from In Last Call by Peterson, Jon|
|2003-04-02||05||Jon Peterson||Shepherding AD has been changed to Peterson, Jon from Mankin, Allison|
|2003-04-02||05||Jacqueline Hargest||State Changes to In Last Call from Last Call Requested by Hargest, Jacqueline|
|2003-04-02||05||Jacqueline Hargest||Status date has been changed to 2003-4-14 from|
|2003-03-31||05||(System)||Last call sent|
|2003-03-28||05||Jacqueline Hargest||State Changes to Last Call Requested from AD Evaluation by Hargest, Jacqueline|
This document is connected to STUN and a related document is SIP...should it be Last Called alone or wait for the SIP one? ...
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.
|2003-01-06||05||Allison Mankin||State Changes to AD Evaluation from Publication Requested by Mankin, Allison|
|2002-11-04||03||(System)||New version available: draft-ietf-mmusic-sdp4nat-03.txt|
|2002-10-30||05||Allison Mankin||State Changes to Publication Requested from AD Evaluation by Mankin, Allison|
|2002-10-22||05||Allison Mankin||State Changes to AD Evaluation -- AD Followup from AD Evaluation -- AD Evaluation of result by mankin|
Gave AD review and got revision, now evaluating. AD
This has been held while we sorted out how it was related to STUN ...
Gave AD review and got revision, now evaluating. AD
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...)
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).
|2002-10-08||05||Allison Mankin||by mankin|
|2002-10-08||05||Allison Mankin||State Changes to AD Evaluation -- AD Evaluation of result from AD Evaluation by mankin|
|2002-10-08||05||Allison Mankin||State Changes to AD Evaluation -- 0 from Publication Requested by mankin|
|2002-07-04||05||Allison Mankin||responsible has been changed to mankin from IESG member|
State Changes to Pre AD Evaluation from Requested ...
State Changes to Pre AD Evaluation from Requested by mankin
|2002-04-13||05||Allison Mankin||Intended Status has been changed to Proposed Standard from Request|
|2002-02-28||02||(System)||New version available: draft-ietf-mmusic-sdp4nat-02.txt|
|2002-02-20||01||(System)||New version available: draft-ietf-mmusic-sdp4nat-01.txt|
|2001-08-24||00||(System)||New version available: draft-ietf-mmusic-sdp4nat-00.txt|