RE: Evaluation: draft-ietf-mmusic-sdp4nat - RTCP attribute in SDP to Proposed Standard

["Peterson, Jon" <jon.peterson@neustar.biz>]

Thanks for your comments, Steven.

First of all, this document wasn't actually supposed to be on the ballot for
this next call - there were some last call comments, and the author is
actually spinning a new version of the draft to fix those (basically,
updates resulting from the transition from RFC1889 to rtp-new-12). I wrote
to the secretariat already asking them to remove the doc from this week's
ballet, but it would be nice if the author could take care of any further
issues (such as those you raise below) in the revision currently underway.

> 
> The discussion in point (4) (of the three-step process....) in Section 
> 3.1 is, in fact, imposing a new requirement on NATs.  This document is 
> a rather subtle place for such a requirment.  I believe that a separate 
> "NAT Requirements to Support SIP" document needs to be written first.
> 

Well, I'm not sure this is really a new requirement on NATs - what
requirement on NATs do you read here? I didn't think 3.1 requires anything
of NATs themselves, merely that clients have a way of ascertaining the port
numbers on the remote side of NATs. STUN provides one way that these port
numbers can be discovered for some existing NATs today. The intention of the
sdp4nat draft is not to change the behavior of NATs themselves in any way,
as far as I know - in terms of protocol mechanism, the only thing it changes
is the information provided in SDP.

There are some existing drafts in the SIP[PING] WGs, most recently the ICE
draft (draft-rosenberg-sipping-ice-00), that paint the big picture for using
SIP, STUN, and the extensions shown in the sdp4nat draft (see 5.4 in ICE on
sdp4nat). I would hope that sdp4nat could progress without a normative
depency on ICE, since it doesn't promote STUN as the only possible solution
for discovering a port number for RTCP on the remote side of the NAT.

> Given that according to this document, only "a large fraction" of NATs 
> behave in the desired fashion today, there needs to be discussion of 
> how an application can discover that it is behind an older NAT.  The 
> alternative is silent failures to connect, which aren't very 
> user-friendly.  The abstract to this document should note that it 
> depends on STUN servers being available.
> 

That discovery discussion does exist in RFC3489 (the STUN RFC, see section
6). Agreed that the abstract of this document could mention STUN, but I'm
not sure that the extensions it describes are useless in the absence of
STUN. Presumably, any method other than STUN for ascertaining the
capabilities of NATs would need to have its own discovery mechanism. Would
it be all right to require in sdp4nat that any NAT discovery mechanism (e.g.
STUN) used by a client that plans to employ sdp4nat must have a way of
ascertaining the suitability of NATs?

As a final note, it is perhaps unfortunate that the document takes NAT as
its exclusive focus, since the mechanism it describes (an SDP attribute for
RTCP port numbers) could be useful for reasons unrelated to NAT, especially
in light of rtp-new-12.

- J

> 		--Steve Bellovin, http://www.research.att.com/~smb (me)
> 		http://www.wilyhacker.com (2nd edition of 
> "Firewalls" book)
> 
>