Subject: [Ietf-behave] AD evalution comments on draft-ietf-behave-nat-udp-05

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Apr 2006 02:01:03 -0700 (PDT)

Hi,

My AD evaluation resulted in the below comments and questions. I do wish 
to have some discussion on some of these topics.

1. Section 4.1: "In particular, in
      the context of SIP, if my application supports the extensions
      defined in RFC 3605 [16] for indicating RTP and RTCP addresses and
      ports separately, but the other peer does not, there may still be
      breakage in the form of the stream losing RTP packets.  This
      requirement will avoid the loss of RTP in this context, although
      the loss of RTCP may be inevitable in this particular example."
Can you please clarify to me why the RTP packets would be lost in this 
case if the pooling is arbitrary?

2. Section 4.2.1, page 9, fourth paragraph:

"For example it will fail if two internal endpoints try to reach the
   same external destination, e.g., a server used by both endpoints such
   as a SIP proxy, or a web server, etc."
I think a web server is a confusing example. I agree that the general 
problem exist, but as a web server would be using TCP this confuses the 
matter in this UDP only document.

3. Section 4.2.1, page 9, fifth paragraph:

"It should be noted that port 0 is reserved and must not be used."

I think there are a number of ports that would be confusing to use as 
source ports. One especially would be port 9 (discard). Thus two 
questions to the WG. Should it be pointed out that there are several 
ports that are not suitable as source ports, and secondly should these 
be enumerated?

4. Section 4.2.1, REQ-3: Why isn't port preservation recommended? Is it 
due to that it can't be guaranteed and therefore there is meaningless to 
recommend it?

5. Section 4.3: REQ-5:
  "A NAT UDP mapping timer MUST NOT expire in less than 1 minute,
      unless REQ-5a applies.
      a) A NAT MAY have UDP mapping timers that have much shorter
         timers, but only for specific ports in the well-known port
         range (i.e., ports 0-1023) where the IANA- registered protocol
         is strictly a request/response protocol, such as for example
         DNS over UDP/53.
      b) The value of the NAT UDP mapping timer MAY be configurable.
      c) A default value of 5 minutes for the NAT UDP mapping timer is
         RECOMMENDED."
I would like to re-open the discussion of the normative timeout period. 
I think 1 minute is to little. I would like at least 5 minutes to avoid 
unnecessary frequent keep-alive traffic. With a one minute timeout 
period the keep-alive will either be ACKed and then likely sent every 
30-45 seconds or so. If not ACKed then people will go for statistical 
guarantees and that will mean 4 to 5 keep-alive packets during that 
minute. That amount of traffic is probably not a big problem for people 
with fixed network. If do create some serious concern for wireless 
devices, both from a cost perspective and also from a battery life-time 
perspective. In services that needs a UDP media channel but sometime are 
inactive these keep-alive will result in a battery consumption during 
idle time that is close to what is used when active. One such service 
that have this behavior is push to talk.

Due to the above I ask the WG if they think 5 minutes would be a better 
compromise. I see at the main problem is the amount of state created in 
the NAT from short duration transactions. However I would like to point 
out requirement 5-a which allows known such protocols to be optimized to 
not keep those states open.

I do also wonder if 5-c is worth the ink it is written with. As long as 
one don't have a reliable way of finding out that time-limit is prior to 
 using it no one can really gain by the recommendation. It is only the 
normative timeout that means anything.

6. Section 8, REQ-11:
"  REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT
      change the NAT mapping or the External Filtering Behavior at any
      point in time or under any particular conditions."
I think that one should include references to the behavior one is 
expecting to be deterministic. I would propose:

   REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT
      change the NAT mapping (Section 4.1) or the External Filtering
      Behavior (Section 5) at any point in time or under any particular
      conditions.
7. Section 9: REQ-12:

"Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping."

Is the use of "destroy" the right word. As the ICMP do not directly 
cause the destruction of the mapping, wouldn't using "terminate" be more 
correct?

8. Section 10.1: Nit: There is a missing empty line between the 
requirement and the justification.

9. Section 10.2, REQ-14:

I don't see how this requirement is connected to the section text? Also 
it is not clear if there is anything more than what is described in 
section 9 and 10.1 that needs to be supported. I think some 
clarification and text changes in regards to this is needed.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@xxxxxxxxxxxx

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 20 Apr 2006 03:38:23 -0700 (PDT)

Hi Magnus - thanks for the careful review. Some comments inline...

PS -  Magnus knows this but just to be clear for others, I am only
commenting on this as an individual contributor. I will Recuse myself from
IESG voting on this and all chair actions to do with this are only dealt
with by Dan (or Jiri in the past).

> case if the pooling is arbitrary?

I suspect we have a typo here and "losing RTP packets" should be " losing
RTCP packets". The RTCP is lost when it the RTCP port can not be signaled
and the n+1 rule is broken by the NAT using ports that are not n and n+1.

> matter in this UDP only document.
Good point. We could use the example of a SIP proxy with SIP over UDP. Are
there other UDP examples that come to mind?

> due to that it can't be guaranteed and therefore there is meaningless to
It was even worse that than that. Statistically speaking from the test done
on NATs, the nats that tried to do port preservation often had much more non
deterministic behavior than the ones that did. For example, we found NATs
that behaved on way on the 1 and 2 conflict but a different way on the 3rd.
Applications that assumed port preservation were more brittle. The more we
thought about it, the more it looked like a) it was impossible in all case
b) it was hard to implement b) trying to do it in some case did more harm
than good

> the NAT from short duration transactions.

I suspect this will be the most contentious of all your comments. I also
find 1 minute very short. One thing did become clear in the WG discussions
on the topic - any value for the time will be picked somewhat arbitrarily.
Everyone agrees the order of magnitude is minutes.

Some issues with short times are they creates huge load on the application
servers in the network. It consumes significant bandwidth. It has
implications on battery life of mobile equipment. The arguments I have heard
for short times fall in two categories: security, and limited number port
resources. Let me comment on both of these

security: The argument goes that 1 minute is more secure than 5 minutes.
I've never really understood this - if the attacker has an attack that works
when the port is open, well this might narrow the window they have to "find"
a victim from 5 minutes to 1 minute but unless we are putting this down to
the milliseconds zone, I don't see how it really makes the attack any harder
to launch. 

limited port resources: the argument here is that the NATs run out of ports
in their port pool and they can't reclaim the existing ports fast enough. In
thinking about this there are a bunch of things to consider. If you have
enough connections to use all the ports in a a few minutes, will that
actually be the limiting resource on the NAT. A totally antidotal sample
point I have on 1 nat in 1 network scenario showed the NAT ran out of CPU
power to process the new flow transactions per second long before it ran out
of ports. I make no claim that this might applied to other nats or other
situations but it did make me wonder. The other things to consider is what
are the clients behind the NAT doing that use up the ports. One things that
has been brought up is they are doing DNS to tons of different DNS servers -
presumably 1000s of DNS servers per second. This particular DNS example can
be easily dealt with using the 5c rule or a recursive DNS server, or a DNS
ALG in the NAT. Testing on a very limited set of NATs did not make it seem
like DNS was a real issue but I could imagine that perhaps some application
like a bulk SPAM sender behind a residential style NAT might have issues
with some NATs around this. The other application that got brought up is
that you have 20,000 phones doing UDP based signaling behind a NAT. The
thing here is that the time is irrelevant - the phones want the number of
flows they want and will do keep alives to keep them all. If the NAT can't
support that many flows, no amount of moving the timer up or down will help
the problem. 

So as you can see, the arguments so far have not help me figure out what
time to use. The thing that I found most compelling was the following...

A goal of BEHAVE is to make it possible to for applications to work but is
also to minimize the changes needed to NATs so there was some hope they
would happen. So the question comes up, what is the time used by NATs today?
Could we find a time that allowed lots of NATs that already exist to be
"behave compliant" as they are today? A large percentage of NATs use 180
seconds. When asked why I get ... because that is what their competitors
use. Some NATs clear use 30 seconds or something a bit over that. At IETF
meetings, operators reported seeing stuff where 30 seconds is too long and
you need to go to 15 seconds but I have not managed to get one of these NATs
in my hands yet to poke at it. Also there are NATs that allow arbitrary
configuration and evidence that some people have configured arbitrary
bizarre things into them.  The WG discussed using 30 seconds since it seemed
like a 99.9% were over that. (I just made up the 99.9% number but as a gut
feeling 30 seconds covers "JUST ABOUT EVERYTHING"). People decided 30
seconds was too short for reasons you mentioned.  The next logical break
point seemed at about 180 seconds as that covered "LOTS" of existing NATs.
(I don't know but this might be like 80% - again totally made up gut feel
number). The 180 got moved to 2 minutes to be conservative or something. 2
minutes was used in WGLC of draft.

This long ramble just provides a brain dump on some of my thoughts on
choosing a time. I'm sure others remember stuff I have forgotten and perhaps
can make a better explanation of the port resource depletion problem than I
have. Over a long time, I became comfortable with 2 minutes - the number is
so arbitrary, I could easily live with changing it. On my lowerbound, 30
seconds is too short. On the upper bound, my biggest worry is that we say 5
minutes, and NAT vendors decide it is "more secure" to implement 3 minutes
because that is what their competitors do. That would be very bad.

> However I would like to point
Just want to be clear this is only know protocols that have a port
registered in the range of 0-1023. Perhaps the text needs to be clearer that
by well-known we explicitly only mean stuff in the 0-1023 range. This seems
like it has potential to cause confusion.

> normative timeout that means anything.
100% agree - some people in the WG liked this - everyone agreed it caused no
harm. I gave up discussing it. I forget what lead to it being here and I
don't know how much push back there would be for removing it - there are
certainly a bunch of people (myself included) that don't care one way or the
other. I hesitate to change it at this point without a strong reason.

>        Behavior (Section 5) at any point in time or under any particular

sure - easy to update.

> cause the destruction of the mapping, wouldn't using "terminate" be more
terminate sounds better to me - will see if anyone objects but sounds like a
good change. 
 
> requirement and the justification.
yep - needs to be fixed. (looks fine in html :-)

> clarification and text changes in regards to this is needed.

I might be missing what you are saying here but .... are you thinking
changing 

REQ-14: A NAT MUST support fragmentation of packets larger than link
      MTU.

to something more like

REQ-14: A NAT MUST support fragmentation of packets larger than link
      MTU by sending an ICMP for any packet larger than the MTU when DF=1
and in the case where DF=0, either break the packet into fragments smaller
than the MTU or send an ICMP error.

Clearly this text would need to be changed to make sense but just wanted to
make sure I was understanding the scope of the change here.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Apr 2006 07:24:12 -0700 (PDT)

Hi,

See inline comments.

Cullen Jennings wrote:
Makes much more sense.

[snipped 2]

No comments on this issue?

Okay, this was just to ensure that I understand things correctly.

5. Section 4.3: REQ-5:
I think 1 minute is to little.
I would like at least 5 minutes to avoid

Thanks for the brain dump. I understand your concern with 5 minutes if 
people do not implement it. If 3 minutes is commonly implemented I would 
think that would be a good compromise of at least raising the bar a bit, 
rather than being ultra-conservative.

Clarity is good.

Sure, it doesn't cause any problems. If people have the opinion that it 
should stay, then let it stay there.

[snip 6]

7. Section 9: REQ-12:

 
[snip 8]

9. Section 10.2, REQ-14:

REQ-14: A NAT MUST support fragmentation of packets larger than link
      MTU by sending an ICMP for any packet larger than the MTU when DF=1
and in the case where DF=0, either break the packet into fragments smaller
than the MTU or send an ICMP error.
Clearly this text would need to be changed to make sense but just wanted to
make sure I was understanding the scope of the change here.
What I don't understand is what is different in Req-13 and Req-14. To me 
REQ-13 applies independently if the packet is going from the internal to 
the external or vice versa.

Cheers

Magnus Westerlund

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 23 Apr 2006 21:36:42 -0700 (PDT)

--- Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx> wrote:

<... stuff deleted>

> > terminate sounds better to me - will see if anyone objects but sounds like
[suresh] This is another requirement that is not UDP specific and is entirely
to do with ICMP error handling. This requirement fully overlaps with the
following requirement in the ICMP behave draft.

   REQ-3: While processing an ICMP error packet, a NAT device MUST NOT 
   refresh or delete the NAT Session that pertains to the embedded
   payload within the ICMP error packet.

I suggest, Req #12 be dropped from the UDP draft. ICMP error hadling should be
deferred to the ICMP behave document, IMHO.

regards,
suresh

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 24 Apr 2006 16:33:24 -0700 (PDT)

On 4/23/06 9:36 PM, "Pyda Srisuresh" <srisuresh@xxxxxxxxx> wrote:

> This requirement fully overlaps with the

Glad you agree now - I seem to recall that you previously felt that the ICMP
draft did not duplicated any of the requirements in the UDP document.

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 25 Apr 2006 06:20:58 -0700 (PDT)

> draft did not duplicated any of the requirements in the UDP document. 
[suresh] I did not say there was no overlap. I said the overlaps did not
conflict. I do believe, ICMP error handling requirement belongs in the ICMP
behave draft.

regards,
suresh