Subject: [Ietf-behave] RE: UDP draft review

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

Thanks. Lots of good comments in there.

See additional clarifications below.

> -----Original Message-----
> From: Saikat Guha [mailto:saikat@xxxxxxxxxxxxxx] 
> Sent: Monday, June 13, 2005 07:53
> To: Audet, Francois [SC100:9T51:EXCH]
> Cc: 'Behave'
> Subject: UDP draft review
> 
> 
> 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.
> 

I guess you are right that they wouldn't be "sessions". It should
really say something like this:

Endpoint Independent Mapping: 

        The NAT reuses the port mapping for subsequent packets sent from the same 
        internal IP address and port (X:x) to any external IP address and port. 
        Specifically, X1':x1' equals X2':x2' for all values of Y2:y2.

Address Dependent Mapping: 

        The NAT reuses the port mapping for subsequent packets sent from the 
        same internal IP address and port (X:x) to the same external IP address, 
        regardless of the external port. Specifically, X1':x1' equals X2':x2' if, 
        and only if, Y2 equals Y1.

Address and Port Dependent Mapping: 

        The NAT reuses the port mapping for subsequent packets sent from the same 
        internal IP address and port (X:x) to the same external and port. Specifically, 
        X1':x1' equals X2':x2' if, and only if, Y2:y2 equals Y1:y1.

> --------
> 
> #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.

Isn't this already covered at great length in section 4.2.1 on
port overloading?

> ---------
> 
> (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)

OK. I will correct.

> (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"?

Yes, I will remove "a NAT that".

> ---------
> 
> (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.

Yeah, the second pair will be deleted.

> -------------
> 
> (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?

Not sure about this. The values we put in there seemed to be acceptable to
most people.

> --------------------
> 
> (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.

I agree.

> --------------------
> 
> (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)

Yeah, it should say:

        Any NAT that changes the NAT mapping or the External Filtering without 
        configuration changes, at any point in time under any particular conditions 
        is referred to as a "non-deterministic" NAT. NATs that don't are called 
        "deterministic".

> --------------------
> 
> (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.

Cullen, can you clarify? 
I'm not sure what we meant here...

> --------------------
> 
> 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)
> 
>

---

From: Saikat Guha <[email-masked]>
Date: Tue, 14 Jun 2005 12:30:26 -0700 (PDT)

On Mon, 2005-06-13 at 21:13 -0400, Francois Audet wrote:
> > #2. Suggestion: 
> > "unless that NAT mapping is already in  
> > use"
> 

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. 

> > 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.

-- 
Saikat
Attachment:
signature.asc