Subject: [Ietf-behave] Two suggestions for BEHAVE document

From: "Francois Audet" <[email-masked]>
Date: Thu, 2 Sep 2004 09:22:48 -0700 (PDT)

I've got 2 suggestions for requirements for the BEHAVE document.

They both relate to faciliting RTP/RTCP traffic WITHOUT doing
deep-packet inspection.

- I'd like to mandate that the port parity (even/odd) be respected
  by the NAT when assigning UDP bindings. This is to respect the RTP=even 
  and RTCP=odd rule. There is some very unfortunate wording in RFC 3550
  section 11, second paragraph, which have caused some problematic
  behavior in client. The wording can be interpreted as saying that
  if a client receives an odd port for sending RTP, it SHOULD change it to
  next lower even number. This would obviously break peer-to-peer media. 

- I'd also like to mandate that for NATs that assign bindings using
  a pool of IP addresses (as opposed to just 1 IP address) on the 
  external side, that the same external IP address be used for all
  bindings to the same internal IP address. For example, if a NAT
  has 10.10.98.12 and 10.10.98.13 on the external side, if internal
  192.168.0.4:5000 sends packets and get assigned 10.10.98.12:6000,
  if 192.168.0.12:45444 then sends packets, it should get assigned
  10.10.98.12:X (and NOT 10.10.98.13:X). The reason for this is
  that I'd like to avoid RTP and RTCP for the same stream having
  different IP addresses. 

I'd like feedback from the group. 

I have seen nice NATs that behave like this. I think these 
requirements are easily met by NATs and will avoid a lot of problems.

PS: People may argue that "extensions" were added to SIP for 
addressing those problems. However, the problem is that the onus is on
the end that is NOT behind the NAT to support them. This is problematic 
because if I make a device that behaves well behind the NAT and does
all the SIP extensions, it will do me no good if the other end doesn't 
implement it because they are not part of the core specification. These 
two simple requirements will avoid the problem altogether. Other protocols
may not even have these extensions.

----
François AUDET, Nortel Networks
Tel: +1 408 495 3756

---

From: Melinda Shore <[email-masked]>
Date: Thu, 2 Sep 2004 09:53:46 -0700 (PDT)

Both sound good with the caveat that there may be situations in
which the NAT runs out of resources (either addresses or ports).
In those cases the NAT has several options, including failing
to create a mapping or creating a mapping that doesn't satisfy
the requirements.  Which way it needs to go depends on whether
you prefer that the NAT's behavior be as deterministic as
possible or that the NAT be as unobtrusive as possible (it's
reasonable to think that most of the traffic traversing a NAT
will not be broken by the NAT in the first place - HTTP,
SMTP, POP, etc.).  At any rate, I think that those two requirements
are reasonable as long as there's some discussion of failure
modes.
Melinda

---

From: Harald Welte <[email-masked]>
Date: Tue, 14 Sep 2004 12:22:20 -0700 (PDT)

>   next lower even number. This would obviously break peer-to-peer media. 

Isn't there also the requirement that RTP/RTCP are on two consecutive
port numbers?  Is this in the specification, or just some broken clients
that require this?  We're currently developing quite complex and ugly
code for consecutive-portnumber-reservation of ALG's :(

Anyway, I don't see any problems with the 'port parity respected'
requirement you would like to add.

>   that I'd like to avoid RTP and RTCP for the same stream having

Yes, this is a commonly-seen problem with NAT implementations.  This
usually breaks lot of applications, even web-based applications, eg.
homebanking.

I fully support adding this requirement to the BEHAVE document.

-- 
- Harald Welte <laforge@xxxxxxxxxxxxx>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie
Attachment:
signature.asc

---

From: Harald Welte <[email-masked]>
Date: Tue, 14 Sep 2004 12:24:10 -0700 (PDT)

On Thu, Sep 02, 2004 at 12:53:13PM -0400, Melinda Shore wrote:
> the requirements.  

It was my current understandign of the existing draft document that in
such a case, a BEHAVE compliant NAT would have to fail, rather than
creating a non-satisfactory mapping.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Sep 2004 13:10:46 -0700 (PDT)

> port numbers?

Yes, the RTP specification requires this, but RFC3605 shows how the
actual RTCP port can be signaled.  This is something we need to mention
in the RTP client specification (which, to my knowledge, nobody has
yet started, but I'm getting an itch here to start it).

> Is this in the specification, or just some broken clients

I bet!  It's a difficult problem with an ALG, but it's even harder
(I would say impossible) if you have a NAT that doesn't ALG your
signaling and that NAT is also really busy with lots of requests
from a bunch of clients -- such as a typical enterprise-scale NAT
would be.

> I fully support adding this requirement to the BEHAVE document.

-d

---

From: Colin Perkins <[email-masked]>
Date: Thu, 16 Sep 2004 02:24:23 -0700 (PDT)

On 14 Sep 2004, at 21:10, Dan Wing wrote:
On Thu, Sep 02, 2004 at 12:22:38PM -0400, Francois Audet wrote:
- I'd like to mandate that the port parity (even/odd) be respected
  by the NAT when assigning UDP bindings. This is to respect
the RTP=even
  and RTCP=odd rule. There is some very unfortunate wording in RFC 
3550
  section 11, second paragraph, which have caused some problematic
  behavior in client. The wording can be interpreted as saying that
  if a client receives an odd port for sending RTP, it SHOULD
change it to
  next lower even number. This would obviously break
peer-to-peer media.

The RTP specification says [RFC 3550, section 11]:

   RTP relies on the underlying protocol(s) to provide demultiplexing of
   RTP data and RTCP control streams.  For UDP and similar protocols,
   RTP SHOULD use an even destination port number and the corresponding
   RTCP stream SHOULD use the next higher (odd) destination port number.
   For applications that take a single port number as a parameter and
   derive the RTP and RTCP port pair from that number, if an odd number
   is supplied then the application SHOULD replace that number with the
   next lower (even) number to use as the base of the port pair.  For
   applications in which the RTP and RTCP destination port numbers are
   specified via explicit, separate parameters (using a signaling
   protocol or other means), the application MAY disregard the
   restrictions that the port numbers be even/odd and consecutive
   although the use of an even/odd port pair is still encouraged.  The
   RTP and RTCP port numbers MUST NOT be the same since RTP relies on
   the port numbers to demultiplex the RTP data and RTCP control
   streams.
The relaxation on the port numbers when explicit signalling is used was 
put in place to ease NAT traversal.

Colin