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

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Sep 2004 16:17:40 -0700 (PDT)

Dan/Harald,

The very first pre-draft that Cullen and I wrote (before we actually 
submitted it) attempted to address the consecutive port number issue.

After reviewing it with others we removed it completely. It was felt that it would be complicated for NAT manufacturers. It was also felt that if a NAT

does not address the contiguous UDP port requirement, the consequence is 
at worst (if either client do not support the RTCP indication) that the
RTCP stream will be lost. This is not a "fatal" problem like loosing the
RTP stream.

However, what Harald is saying is worrying me (i.e., "We're currently developing quite complex and ugly code for consecutive-portnumber-

reservation of ALG's").

I think that there is a very good chance based on past experience that
if NAT vendors use different algorithms for preserving consecutive port
numbers, we will end-up in trouble.

So I think that we need to discuss the issue in the document. 

Perhaps it's as simple as saying that we don't recommend putting hacks in
the NAT to address the issue because of reasons X, Y, Z.

As I said earlier, we had tought of ways to address the issue (by doing
port reservations and sequential assignment), but it grew more complex
and we utimately didn't include them.

Any views from others?

> -----Original Message-----
> From: Dan Wing [mailto:dwing@xxxxxxxxx]
> Sent: Tuesday, September 14, 2004 13:11
> To: Harald Welte; Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Behave'
> Subject: RE: [Ietf-behave] Two suggestions for BEHAVE document
> 
> 
> > 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.
> >
> > Isn't there also the requirement that RTP/RTCP are on two
> consecutive
> > 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
> that require
> > this?  We're currently developing quite complex and ugly code for
> > consecutive-portnumber-reservation of ALG's :(
> 
> 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.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 14 Sep 2004 18:32:24 -0700 (PDT)

inline.

Francois Audet wrote:

Agreed.

Perhaps it's as simple as saying that we don't recommend putting hacks in
the NAT to address the issue because of reasons X, Y, Z.
Well, normally, one doesnt include in the document all of the design 
choices that the group elected NOT to pursue. I think our objective is 
to document the recommended solution and explain why it is the 
recommended solution. If Harald or others have concerns about the port 
affinity approach, we should discuss that and conclude on a 
recommendation. I for one like the port affinity solution.

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@xxxxxxxxxxxxxxx                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Harald Welte <[email-masked]>
Date: Wed, 15 Sep 2004 03:11:21 -0700 (PDT)

On Tue, Sep 14, 2004 at 07:16:24PM -0400, Francois Audet wrote:
> Dan/Harald,
> 
> After reviewing it with others we removed it completely. It was felt that it
> would be complicated for NAT manufacturers. It was also felt that if a NAT

I can understand this position.  However, wasn't RTCP thought of a means
to communicate packet loss rates?  If I put this in context with the IAB
problem statement on congestion control, I doubt it is a good idea to
just silently prevent RTCP from working.

> However, what Harald is saying is worrying me (i.e., "We're currently
> developing quite complex and ugly code for consecutive-portnumber-
> reservation of ALG's").

Well, there are developers working on a SIP ALG for netfilter, and they
asked us to include infrastructure for consecutive port number
reservation into the netfilter NAT core.  Our current position on this
is 

1) consecutive port numbers are a bad idea, somebody should LART the
   protocol designers
2) now that we are facing the problem, we have to come up with a
   solution (i.e. implement it).

> numbers, we will end-up in trouble.

We'd just chose any two (or even four in the case of A/V streams?)
consecutive port numbers that are available.  Just like we would chose
any single available port number.

> the NAT to address the issue because of reasons X, Y, Z.

I would definitely like that.  It saves us from those hacks in the code.
However, it should then be considered to alter the RTP/RTCP
specification to not require those consecutive port numbers in the
first place.

Either the protocol changes, or the NAT's will have to adress it.  I
don't see any way in between.

-- 
- 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: Cullen Jennings <[email-masked]>
Date: Wed, 15 Sep 2004 10:22:59 -0700 (PDT)

> don't see any way in between.

Yep, I think this is the heart of it. So we are in one of the gray area's
where we make a judgment call - we have two choices - both could work.

A) Don't do consecutive port stuff on NAT. This means RTP applications will
need to use RFC 3605 to work through NATs. (as well as RFC 3489)

B) Force NATs to do consecutive port assignment.

A is a change for many RTP program, but none of this is going to work
without changes to them such as supporting STUN.

B is a *big* change for the NAT vendors. The way the draft is written now,
many NATs would be compliant with it and many others would require only very
small changes. 

I think I lean in favor of A over B because I think that the people that
have to do the work for B have far less incentive to do the work than the
people that have to do the work for A. Thus I view A as more likely to
succeed than B. 

As a side note, RTP is the only protocol I am aware of that would desires
NATs to  have this behavior.

Cullen