Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Aug 2004 17:28:55 -0700 (PDT)

OK. Perfect. Thanks.

Should we keep ICMP and Fragmentation as separate items, or should
they be combined? (In the current document, they are separate).

Any suggestions on wording are welcomed.

> -----Original Message-----
> From: Dan Wing [mailto:dwing@xxxxxxxxx] 
> Sent: Tuesday, August 31, 2004 17:22
> To: Audet, Francois [SC100:9T51:EXCH]; 'Behave'
> Subject: RE: [Ietf-behave] Where we are with draft-audet-nat-behave
> 
> 
> ...
> > 2 - I believe we have a broad concensus that this first
> > document will ONLY cover UDP Unicast. TCP, Multicast, ICMP, 
> > etc. are to be covered in later draft(s). 
> 
> I believe we need to cover UDP and ICMP as the received ICMP 
> message apply to those UDP packets that were sent by the NAT.
> 
> If a NAT 'eats' an ICMP message, or uses a certain ICMP message 
> to close its UDP binding, it has significant operational 
> effects on an application -- especially if the application 
> didn't receive the ICMP message (due to congestion on the
> home Ethernet network or home wireless network, for example).
> 
> Similarly, I believe the TCP document needs to describe ICMP
> as those ICMP messages apply to the TCP packets that were 
> sent by the NAT.
> 
> > 3 - I'm not sure if we should include fragmentation or
> > not (any views?). 
> 
> I agree with Geoff - the handling of fragmentation is 
> variable and needs to be discussed.  This doesn't mean we'll 
> necessarily require reassembly in a NAT to be 
> BEHAVE-compliant, but we need to describe how fragmentation 
> in should be handled.
> 
> We need to discuss both incoming fragmentation (packet 
> arrives in fragments) and outgoing fragmentation (I believe 
> there are two cases, (a) host set DF=1, and NAT discovers the 
> access link 
> is too small to handle it [PPPoE], and (b) NAT sends packet 
> and receives ICMP 'fragmentation needed DF set' packet, what 
> should it do.
> 
> To do this, we'll need to mention ICMP ('fragmentation needed 
> DF set').
> 
> ...
> > Can you guys tell me what you think?
> 
> The others items all sound fine to me.
> 
> -d
> 
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 1 Sep 2004 04:46:51 -0700 (PDT)

So, we're talking about the difference between NAT effects on 
traffic that is actually fragmented, and NAT effects on P-MTU Discovery, 
right?
 
These seem to be separate topics in my mind.
 
Spencer
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  ----- Original Message ----- 
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black">From: 
  <A title=audet@xxxxxxxxxxxxxxxxxx 
  href="mailto:audet@xxxxxxxxxxxxxxxxxx">Francois Audet 
  To: <A title=dwing@xxxxxxxxx 
  href="mailto:dwing@xxxxxxxxx">'Dan Wing' ; <A 
  title=ietf-behave@xxxxxxxxxxxxxxxxxxx 
  href="mailto:ietf-behave@xxxxxxxxxxxxxxxxxxx">'Behave' 
  Sent: Tuesday, August 31, 2004 7:27 
  PM
  Subject: RE: [Ietf-behave] Where we are 
  with draft-audet-nat-behave
  
  OK. Perfect. Thanks. 
  Should we keep ICMP and Fragmentation as separate items, or 
  should they be combined? (In the current document, 
  they are separate).

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 1 Sep 2004 08:51:23 -0700 (PDT)

> OK. Perfect. Thanks.
>
> Should we keep ICMP and Fragmentation as separate
> items, or should they be combined? (In the current
> document, they are separate).

There are three issues around fragmentation:

  1. The NAT trying to send a packet that exceeds the
     MTU of the local access link.  This can occur
     if the NAT is doing PPPoE, as is common on many
     DSL networks.  This packet could have DF=1 or
     DF=0.

     If it has DF=1, we need to describe what the
     NAT should do (I suggest a properly-behaving
     NAT would behave like a router in this instance,
     and send back an ICMP message to the host, and
     the host then Does The Right thing per Path MTU
     Discovery).  A question, though, is how well
     PMTUD works for UDP in Windows and various other
     common PC operating systems.  PMTUD has been
     historically pretty spotty for TCP..

     If it has DF=0, the NAT should fragment the packet
     and send the fragments.  This is the same function
     a router performs with DF=0 and a smaller MTU on
     the egress interface.

  2. The NAT sending a packet that exceeds the MTU
     of some link in the middle of the network.  In this
     case the NAT will receive an ICMP 'fragmentation
     needed DF set' message.  I suggest we follow the
     router requirements here, too, and that the NAT
     is sends the ICMP message to the host.  This incoming
     packet cannot destroy the NAT binding.  I don't care
     if the incoming packet extends the lifetime of the
     binding.

  3. The NAT receives a fragmented UDP packet.  The
     IP packet containing the UDP header could arrive first
     or last - depending on network conditions, packet ordering,
     and the implementation of the sending IP stack.

     The easiest thing is to discard such packets.  However,
     this is problematic for relatively obvious reasons.

     The easiest thing which works well is to keep the fragments
     in memory and, when the fragment containing the UDP header
     is received, to send all of the fragments to the appropriate
     NAT binding.  This has obvious denial of service implications,
     though, but we can discuss several mitigations that implementors
     can safely use.

I feel that (1) and (2) can be discussed together, and (3) should be in a
separate section, like you have them now.  But I think (1) and (2) are
sufficiently distinct that they should be discussed individually.

> Any suggestions on wording are welcomed.

I'll try to get a few paragraphs built later this week.

-d

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Sep 2004 10:10:11 -0700 (PDT)

In the case where some fragment other than the first arrives before the
first fragment, I'm not sure I like the idea that the NAT should save the
fragments and send them later. It seem like it would be really complicated
to correctly do the memory management to make this work reliably and not
have a huge DOS opportunity.

Cullen

On 9/1/04 8:51 AM, "Dan Wing" <dwing@xxxxxxxxx> wrote:

> _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Sep 2004 11:48:17 -0700 (PDT)

I agree.

The trouble with UDP is that, unlike TCP, most stacks don't do Path MTU
Discovery for UDP and thus fragmentation is more likely with UDP than with
TCP.  This is seldom noticed with voice as the packets are small, but will
be more commonplace with video especially in conjunction with PPPoE, IPsec,
or if someone configures a link with a small MTU to reduce serialization
delay.

However, the alternative to properly handling fragments means that
fragmented UDP packets may, or may not, make it across the NAT depending on
(a) how the NAT handles fragments arriving out of order, (b) if the network
reordered the fragments, and (c) if the host (or router) that fragmented the
packets transmitted the fragments in order.

I don't feel the alternative meets the spirit of BEHAVE.  But perhaps we can
provide the necessary guidance in the 'how client should function with a
BEHAVE-compliant NAT' document, namely: do PMTUD with UDP, and if you have
to fragment send the fragments in-order.  As we can't control the routers in
the network, though, so it's best to do PMTUD with UDP.

-d

> From: Cullen Jennings [mailto:fluffy@xxxxxxxxx]
> Sent: Tuesday, September 14, 2004 10:10 AM
> To: Dan Wing; Francois Audet; Behave
> Subject: UDP packet fragmentation
>
>
>