Subject: [Ietf-behave] UDP draft review

From: Saikat Guha <[email-masked]>
Date: Mon, 13 Jun 2005 08:26:19 -0700 (PDT)

Bunch of comments on the UDP draft below. This is based on the draft
current as of Thursday; so there may be some differences compared to the
ID.

-------------

(sec 4.1)
>     Address and Port Dependent Mapping:
>        The NAT reuses the port mapping for subsequent sessions
>        initiated from the same internal IP address and port (X:x) only
>        for sessions to the same external and port.  Specifically,
>        X1':x1' equals X2':x2' if, and only if, Y2:y2 equals Y1:y1.

#1. Ambiguity:
What is meant by "subsequent sessions"? If you mean UDP packets with the
same src and dst IP and port ... aren't they part of the same "session"
as defined earlier? Do you mean "subsequent sessions" as in a UDP packet
sent long after the last packet of a previous session.

If you mean the former, may I suggest something along the lines of "the
NAT does not reuse the port mapping" for different sessions. If you mean
the latter, then this terminology does cannot adequately define existing
behavior -- some existing NATs pick different mappings for X:x->Y:y at
different times of the day based on mappings in use at the moment.

--------

#2. Suggestion:
In all these NB=x cases, perhaps an exception should be made to
accommodate NATs that avoid port-collisions. Something along the lines
of "unless that NAT mapping is already in use" should suffice. I am
concerned about a NAT implementation that computes the mapping based on
a deterministic function F(X,x) => X1':x1'. By definition this function
has to be many-to-one. It satisfies the requirements for NB=I. But a
correct implementation needs to ensure that X1':x1' isn't already
allocated (to avoid port overloading); therefore fundamentally F cannot
always be deterministic. When classifying NATs, we should explicitly
allow for the tiny non-determinism required for port-
collision/overloading-resolution; thats what my suggestion ties to
capture.

---------

(sec 4.2.1, sec 12)
> REQ-3: IA NAT MUST NOT have a "Port assignment" behavior of "Port

#3. Typo:
IA -> A (both in section 4.2.1 and  12)

---------

(sec 4.2.1)
> However, it should be understood
> that a NAT that when a port is randomly assigned, it may just
> randomly happen to be assigned the same port.

#4. Typo:
"that a NAT that when"?
---------

(section 4.2.2)
> Some NATs preserve the parity of the UDP port, i.e., an even port
> will be mapped to an even port, and an odd port will be mapped to an
> odd port.  This behavior respects the RFC 3550 [8] rule that RTP use
> even ports, and RTCP use odd ports.  Some NATs preserve the parity of
> the UDP port, i.e., an even port will be mapped to an even port, and
> an odd port will be mapped to an odd port.  This behavior respects
> the RFC 3550 rule that RTP use even ports and RTCP use odd ports when
> the application takes a single port number as a parameter and derives
> the RTP and RTCP port pair from that number.  

#5. Typo:
The first two sentences are redundant. Or perhaps the last two.

-------------

(section 4.3)
> NAT mapping timeout implementations vary but include the timer's
> value and the way the mapping timer is refreshed to keep the mapping
> alive.

#6. Suggestion
In light of Yutaka's recent suggestion to require per-session filter
scope (see other thread), should this timeout be increased? One
mitigating circumstance is that this holds only for idle sessions. With
the existing values, 120 clients on a RTP or VoIP server (with silence
suppression) will govern a 1 packet per second overhead. Any estimates
on the typical number of clients (tens, hundreds, thousands) and the
acceptable overhead for such applications?

--------------------

(section 5.2)

#7. Suggestion
Add

REQ-x: It is RECOMMENDED that a NAT have "NAT filter Refresh Scope"
  behavior of "Per Session".

(see other thread for details)

--------------------

(section 7)
> a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow
>    the user to enable or disable each ALG separately.

#8. Ambiguity
There was some talk about defining "user". Perhaps it should be changed
to "NAT administrator" here.

--------------------

(section 8)
> Any NAT that changes the NAT mapping or the External Filtering at any
> point in time under any particular conditions is referred to as a
> "non-deterministic" NAT.

#9. Ambiguity
... unless it is response to a configuration change by the NAT
administrator (REQ-7a)

--------------------

(section 9)
>   a) The ICMP timeout SHOULD be greater than 2 seconds.

#10. Ambuguity
ICMP timeout has not been defined in this context. I don't even have a
good guess as to what it could mean. If you mean that an ICMP received
more than 2 seconds after the outgoing UDP packet that triggered the
ICMP need not be translated, then I point out that the RFC recommended
MSL is 2 minutes. In any case, such a timeout seems redundant since it 
doesn't affect security. If you mean timeout in the sense that no ICMP 
packets should be generated or translated within 2 seconds of an ICMP 
that is processed, then it prevents an one or more endpoint from doing 
parallel MTU discovery to different hosts.

--------------------

Cheers.

-- 
Saikat
(Note to self: Next time when I get stranded for 8 hours, I must have
some other reading material on me than just the UDP draft)

Attachment:
signature.asc

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 14 Jun 2005 17:13:18 -0700 (PDT)

> On Mon, 2005-06-13 at 21:13 -0400, Francois Audet wrote:
> > > #2. Suggestion:
> > > "unless that NAT mapping is already in  
> > > use"
> > 
> > Isn't this already covered at great length in section 4.2.1 on
> > port overloading?
> 
> It is, but in the changes you proposed "subsequent packets" 
> is not defined to exclude packets send after a mapping 
> expires ... which are still 'subsequent packets' as far as 
> the English language is concerned but need not be allocated 
> the old mapping for the NAT to be classified such. 

OK. I'll clarify.

> > > scope (see other thread), should this timeout be increased?
> 
> > Not sure about this. The values we put in there seemed to be 
> > acceptable to most people.
> 
> When it was discussed before, was it under the assumption 
> that all endpoint-sessions would need a keep-alive (NAT 
> filter refresh scope of per session or equivalent) or just 
> one keep-alive would refresh all endpoint-sessions (scope of 
> per-mapping). If it was the first case, then my question is 
> merely for clarification; if not, then the keep-alive traffic 
> is now significantly more than when it was last discussed.

Yes. It we now expect multiple keep-alives, then indeed the traffic
is increased (which is why the draft tried to avoid the need for
multiple keep-alives).