Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt

From: Cullen Jennings <[email-masked]>
Date: Sun, 1 Apr 2007 15:27:45 -0700

On Mar 26, 2007, at 1:13 AM, Lars Eggert wrote:

> On 2007-3-26, at 9:35, ext Saikat Guha wrote:
>> Allowing or disallowing ICMP on a local network is a policy issue for
>> the site. This site policy is out-of-scope of BEHAVE. What IS in  
>> scope,
>> as Cullen said, is specifying how those packets are to be  
>> translated if
>> site policy permits.
>
> If ICMPs were completely advisory, I'd agree, but they aren't  
> (yet). Some ICMP messages are needed for the correct operation of  
> transport protocols (must fragment), others are increasing  
> efficiency (unreachables, etc.)
>
> .

Completely agree with Lars here - that is why the parts of ICMP that  
are need to make UDP work are put into the behave document for UDP,  
and likewise for other transport protocols.  They clearly need to be  
there otherwise we run the risk of the behave documentation around  
ICMP actually breaking transport protocols which would be clearly not  
the right path.

This ICMP document is to deal with the ICMP applications that are not  
associated with a transport protocol. I seem to recall that the only  
two applications that the WG identified were ping and traceroute but  
perhaps there were more. The general reports from testing NATs seem  
to be that for clients inside the NAT running an ICMP application to  
something outside the NAT, the ping and treaceroute applicants seems  
to work fine. You will note after an long an irritating discussion on  
this list I actually went and tested ping and traceroute on about 50  
nats and published the result in a draft.

Cullen <with my individual hat on>

_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "David Barrett" <[email-masked]>
Date: Sun, 1 Apr 2007 17:42:03 -0500

> ICMP actually breaking transport protocols which would be clearly not

I'm not sure I agree they "clearly" need to be there, or that transport
protocols "break" with the absence of ICMP:

In my experience UDP works just fine in environments without ICMP -- indeed,
you'd be crazy to depend upon it.  Every UDP protocol that I've used
(including those that I develop) treats ICMP as a nice, but rarely available
and totally unreliable perk.  

Even TCP, so far as I understand it, has well-paved fallbacks for if ICMP is
unavailable (indeed, isn't ICMP availability technically a "special case" in
the TCP stack?).  Sure it might mean longer timeouts, greater packet loss,
and smaller MTUs, but that's hardly the same as "correct operation".  TCP
works "correctly" without ICMP, just differently.

So while I totally agree we should encourage ICMP and define the "right" way
to support it, I'm not sure it should be made mandatory for BEHAVE
compliance.

Again, I love ICMP, and I want it.  But not everybody loves and wants it as
much as me.

-david

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 1 Apr 2007 16:54:03 -0700 (PDT)

--- Cullen Jennings <[email-masked]> wrote:

> and likewise for other transport protocols.

[suresh] Cullen - With the excpetion of UDP document, it has been the consensus
of the WG to include ICMP requirements in the ICMP document. For example, In
the San Diego meeting, the consensus was to have the ICMP doc specify the
translation of ICMP messages, and leave the reaction up to each
protocol-specific document. ICMP document is transport protocol agnostic.

>                                             They clearly need to be  
[suresh] Right.

> associated with a transport protocol. 

[suresh] Cullen - We had gone over the scope of ICMP doc before and settled on
this. Why are you bringing this up again? If you restricted the scope of ICMP
behave docuemnt to applications of ICMP Query messages, the draft adds little
value. REQs 3, 4, 5, 7, 8 and 9 are requirements relating to ICMP error
messages, - That is 67% of the total requirements in the document. These
requirements are not covered in other BEHAVE documents.

regards,
suresh

>                                       I seem to recall that the only

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 1 Apr 2007 17:47:36 -0700 (PDT)

> Again, I love ICMP, and I want it.  But not everybody loves and wants it as

[suresh] David - RFC 1812 mandates that routers generate, interpret and forward
ICMP error messages. ICMP signaling is required on all IP routers. The soft
requirement you are refering to (TCP works without ICMP, but just differently)
comes from the fact that ICMP messages are sent as IP datagrams and IP
datagrams are not guaranteed. That is not to say that ICMP support on the
routers is optional. As Lars said, without ICMP, the operation of transport
protocols will be impeded in correctness and efficiency.

regards,
suresh

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 2 Apr 2007 09:28:53 +0300

> protocols "break" with the absence of ICMP:

I do.

> In my experience UDP works just fine in environments without ICMP --
> indeed, you'd be crazy to depend upon it.  Every UDP protocol that I've
> used (including those that I develop) treats ICMP as a nice, but rarely
> available and totally unreliable perk.

In my experience, nothing works without ICMP Packet too big. I happen to have 
lived in a country where there is intense use of PPPoA or PPPoE on the last 
mile, so that the MTU is lower between the CPE and ISP (typically 1492 bytes) 
than on the LAN (1500) and on the Internet (at least 1500).

Saying that packet too big can be dropped is like saying you do not care 
about "talking" with these users (the last ISP router will send Packet too 
big if you try to send them a packet). I'm talking *millions* of them here.

> Even TCP, so far as I understand it, has well-paved fallbacks for if ICMP
> is unavailable (indeed, isn't ICMP availability technically a "special
> case" in the TCP stack?). Sure it might mean longer timeouts, greater
> packet loss, and smaller MTUs, but that's hardly the same as "correct
> operation".  TCP works "correctly" without ICMP, just differently.

Not at all. TCP does not work at all without ICMP. Because of this, most NAT 
boxes have to do MSS clamping to fix it (in the same scenario as above). 
Otherwise, you get your three-way handshake fine, and then the connection 
breaks as soon as you send too large a data packet.

-- 
Rémi Denis-Courmont

---

From: "David Barrett" <[email-masked]>
Date: Mon, 2 Apr 2007 01:57:04 -0500

> -----Original Message-----
> From: Rémi Denis-Courmont [mailto:[email-masked]]
> 
> In my experience, nothing works without ICMP Packet too big. 

"Nothing" is a very strong word that you might take more care with.  To list
a few, RTP, RTCP, my personal UDP protocols (iGlance -- streaming
voice/video/file/screen-sharing, Red Swoosh -- swarming downloads) don’t
require ICMP.  UPnP works without ICMP.  DNS does too, so far as I know.
Yes, all of these work better *with* it.  But to say that nothing works
without ICMP seems patently false.

> I happen to
> have

All the UDP developers I know use packet sizes smaller than 1492 for
precisely this reason.  I generally target the 1KB range.  UDP fragmentation
from too-large packets leads to high packet loss (and this is true with or
without ICMP), which is why everybody strives to avoid it. 

Again, I love ICMP.  It makes everything work better.  But let's not pretend
nothing can function without it.

> big if you try to send them a packet). I'm talking *millions* of them

The "secret" is to just send small packets.  People who do real-world UDP
protocol design and programming know this, and have already been doing this
for years.  ICMP is nice.  It's not required.

> breaks as soon as you send too large a data packet.

Again, that's a very absolute statement that I'm pretty sure is wrong.  TCP
*can* function without ICMP.  It might require some extra work, extra
delays, and extra headaches.  But it can and does work every day.

I agree BEHAVE should specify how ICMP should be supported, if it's to be
supported.  But I disagree it should mandate ICMP be supported, anymore than
it should mandate UPnP be supported merely because "it makes things work
better".

-david

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 2 Apr 2007 10:33:45 +0300

> delays, and extra headaches.  But it can and does work every day.

Sure, if you the smallest MTU in the path in on the first hop, it works just 
fine. Otherwise, it times out lamely as soon as the outpout buffer gets 
bigger than the path MTU, and the TCP stacks keeps retrying to transmit a 
packet that gets silently dropped (using widespread TCP stacks such as 
Windows XP and Linux).

> supported.  But I disagree it should mandate ICMP be supported, anymore
> than it should mandate UPnP be supported merely because "it makes things
> work better".

It makes some things work at all, which is very different.

-- 
Rémi Denis-Courmont

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 2 Apr 2007 06:06:03 -0700 (PDT)

> packet that gets silently dropped (using widespread TCP stacks such as 
[suresh] Exactly. The point is not so much as whether TCP protocol is
theoretically resilient to ICMP support in the network. The point, as Remi
says, is that applications fail without it. 

[suresh] Right. 

David - RFC1812 mandates routers to generate, interpret and forward ICMP error
messages. It is manadatory for a router to support ICMP error messages. Why do
you believe ICMP support is not mandatory for a NAT device, whose principal
functionality is routing between private and public realms?

regards,
suresh

---

From: Lars Eggert <[email-masked]>
Date: Mon, 2 Apr 2007 16:19:05 +0300

On 2007-4-2, at 1:27, ext Cullen Jennings wrote:
> Completely agree with Lars here - that is why the parts of ICMP  
> that are need to make UDP work are put into the behave document for  
> UDP, and likewise for other transport protocols.  They clearly need  
> to be there otherwise we run the risk of the behave documentation  
> around ICMP actually breaking transport protocols which would be  
> clearly not the right path.
>
> This ICMP document is to deal with the ICMP applications that are  
> not associated with a transport protocol. I seem to recall that the  
> only two applications that the WG identified were ping and  
> traceroute but perhaps there were more.

Ah. It wasn't clear to me that behave-nat-icmp was only focussing on  
ICMP translation that wasn't somehow related to transport protocols.  
It'd be very useful to put something like your explanation above into  
the abstract and introduction of the document.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 2 Apr 2007 16:23:22 +0300

> and totally unreliable perk.

Probably true.

> works "correctly" without ICMP, just differently.

Not true - see the Section on black holes in RFC2923.

Once hosts implement the new method for PMTUD (RFC4821, just  
published), things will be different, but that can take a long time.

Lars

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 2 Apr 2007 06:49:59 -0700 (PDT)

> the abstract and introduction of the document.

[suresh] Lars - behave-nat-icmp is transport protocol agnostic and specifies
the translation of ICMP messages (Ex: req 3, 4, 5, 7). The specification of how
an embedded payload specific to a transport protocol is transalted (or) how a
NAT ought to react to a payoad is left to transport protocol specific BEHAVE
documents.

regards,
suresh

---

From: "David Barrett" <[email-masked]>
Date: Mon, 2 Apr 2007 10:15:23 -0500

My understanding is BEHAVE-compliance basically means "the protocols
supported on this device are correctly translated", and not "applications
will work well with this gateway device".  That latter seems like a much
bigger and more nebulous topic.

So it still sounds like the two approaches are:

1)   Mandate all BEHAVE-compliant gateway devices support ICMP
2) Recommend all BEHAVE-compliant gateway devices support ICMP

I still favor taking a protocol-by-protocol approach: if you claim to
support protocol X, here's the proper way to perform NAT translation.  I'd
continue favoring this approach even if it were shown ICMP were truly
critical.  Fundamentally, the choice of which protocols to support is a
filtering decision, which (I think) is out of BEHAVE scope.

-david

Remi -- As for the XP and Linux TCP stacks, you're saying that when they
ramp their transmit window up to larger than the path MTU they will *never*
recover without ICMP?  They will never timeout and retry a smaller packet?

Pyda -- As for RFC1812 mandating ICMP, that's great.  Then there's no reason
to re-mandate it here.  If BEHAVE says "if you support ICMP, do X", and if
everyone is compliant with RFC1812, then everyone will "do X".   But if
someone doesn't support ICMP, then they're not compliant with RFC1812, which
seems like a bigger deal than whether or not they comply with BEHAVE.
Alternatively, let's say for whatever reason RFC1812 were changed to no
longer require ICMP.  Should BEHAVE supersede that decision and still
require it?  Why the redundancy?

-david
 
> From: Pyda Srisuresh [mailto:[email-masked]]
> Sent: Monday, April 02, 2007 8:06 AM
> To: Rémi Denis-Courmont; ext David Barrett; [email-masked]
> Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt
> 
> 
> > > > Not at all. TCP does not work at all without ICMP. Because of this,
> most
> > > > NAT

---

From: Lars Eggert <[email-masked]>
Date: Mon, 2 Apr 2007 18:27:35 +0300

> 2) Recommend all BEHAVE-compliant gateway devices support ICMP

We discussed another option, too:

(3) Recommend that BEHAVE compliant devices that translate transport  
protocol X also translate ICMP messages Y and Z, because X's correct  
operation depends on them.

(So, if your NAT translates TCP it should translate ICMP "packet too  
big", because otherwise you can run into blackholes. If it doesn't  
translate TCP, maybe it doesn't need to translate that ICMP message.)

I think that is similar what you describe here:

> support protocol X, here's the proper way to perform NAT translation.

It's just that the "proper way" may include translating some ICMP  
messages.

> recover without ICMP?  They will never timeout and retry a smaller  

(1) TCP windows are unrelated to segment sizes.
(2) There are _many_ end system stacks other than Linux and XP out  
there.
(3) There are TCP implementation techniques (did you look at  
RFC2923?), but they are not standards recommendations.

Lars

---

From: "David Barrett" <[email-masked]>
Date: Mon, 2 Apr 2007 11:03:23 -0500

> From: Lars Eggert [mailto:[email-masked]]
> >

Ah, I like this plan.  I'm sorry I didn't catch onto it before.

-david

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 4 Apr 2007 13:56:18 -0700

Lars Eggert wrote:

> > will work well with this gateway device".  That latter 
> > seems like a much bigger and more nebulous topic.
> >

Yes, and that 3rd option is what our TCP document does.  As a specific
example of this text, the TCP document says:

   ...
   7.  Other Requirements Applicable to TCP

   A list of general and UDP specific NAT behavioral requirements are
   described in [BEHAVE-UDP].  A list of ICMP specific NAT behavioral
   requirements are described in [BEHAVE-ICMP].  The requirements listed
   below reiterate the requirements from these two documents that
   directly affect TCP.  The following requirements do not relax any
   requirements in [BEHAVE-UDP] or [BEHAVE-ICMP].
   ...
   7.3.  ICMP Responses to TCP Packets

   ICMP responses are used by end-host TCP stacks for Path MTU Discovery
   and for quick error detection.  ICMP messages are rewritten by the
   NAT (specifically the IP headers and the headers inside the ICMP
   payload) and forwarded to the appropriate internal or external host.
   Blocking any ICMP message is discouraged.

   REQ-9:  Receipt of any sort of ICMP message MUST NOT terminate the
      NAT mapping or TCP connection for which the ICMP was generated.

   Justification:  This is necessary for reliably performing TCP
      simultaneous-open where a remote NAT may temporarily signal an
      ICMP error.  It is also useful for MTU discovery.
   ...

Which has been the consensus of the working group.

-d

> > I still favor taking a protocol-by-protocol approach: if you 
> > claim to support protocol X, here's the proper way to perform 
> > NAT translation.
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 4 Apr 2007 09:57:29 -0700

On Apr 1, 2007, at 4:54 PM, Pyda Srisuresh wrote:

> of the WG to include ICMP requirements in the ICMP document.

What you are saying here is not what I was saying and also not my  
understanding of what the group agreed with it's ADs on. It is true  
the ICMP document has requirements related to ICMP - however, the  
requirements about what ICMP needs to do for protocol X, need to be  
in the protocol X document. Part of the reason the WG went down this  
path was that if we make ICMP include what is needed for all  
protocols, it is very hard to  know when we can call the ICMP  
document done. Another reason has to do with the point that the NAT  
will need to implement the ICMP handling for, say SCTP, when the NAT  
implements SCTP, not when the NAT developer implements UDP. Another  
reason had to with he expertise to review the   ICMP for protocol X  
was probably best to review the ICMP for protocol X at the same time  
as the behave document for protocol X.

I don't think anything is changing here - this is roughly my  
understanding from awhile back.

Cullen < with my individual hat on>

)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HZFNI-00054g-Iy
	for [email-masked]; Wed, 04 Apr 2007 19:58:48 -0400
From: Cullen Jennings <[email-masked]>
Subject: Re: [BEHAVE] draft-ietf-behave-nat-icmp-03.txt
Date: Wed, 4 Apr 2007 09:57:29 -0700
To: Pyda Srisuresh <[email-masked]>
Cc: Behave WG <[email-masked]>

On Apr 1, 2007, at 4:54 PM, Pyda Srisuresh wrote:

> of the WG to include ICMP requirements in the ICMP document.

What you are saying here is not what I was saying and also not my  
understanding of what the group agreed with it's ADs on. It is true  
the ICMP document has requirements related to ICMP - however, the  
requirements about what ICMP needs to do for protocol X, need to be  
in the protocol X document. Part of the reason the WG went down this  
path was that if we make ICMP include what is needed for all  
protocols, it is very hard to  know when we can call the ICMP  
document done. Another reason has to do with the point that the NAT  
will need to implement the ICMP handling for, say SCTP, when the NAT  
implements SCTP, not when the NAT developer implements UDP. Another  
reason had to with he expertise to review the   ICMP for protocol X  
was probably best to review the ICMP for protocol X at the same time  
as the behave document for protocol X.

I don't think anything is changing here - this is roughly my  
understanding from awhile back.

Cullen < with my individual hat on>

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 8 Apr 2007 21:44:53 -0700 (PDT)

> understanding from awhile back.
[suresh] Right, the ICMP document will not include requirements on what needs
done on NAT to react to ICMP messages for specific protocol X. We are on the
same page. Thanks.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 8 Apr 2007 22:07:42 -0700 (PDT)

I agree.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 8 Apr 2007 22:46:28 -0700 (PDT)

David,

Please see my comments inline.

regards,
suresh

<... stuff deleted>
> seems like a bigger deal than whether or not they comply with BEHAVE.

[suresh] Dave - Not all NAT devices confirm to RFC1812 requirements. For
example, take the case of honoring the DF bit in an IP header. If the DF bit is
set on a packet and NAT cannot forward the packet without packet fragmentation,
the NAT MUST send "packet too big (3/4)" message back to sender. Not all NATs
do this. Hence the reason to mandate RFC1812 in this document.

> require it?  Why the redundancy?

[suresh] Firstly, RFC1812 will remain unchanged. However, there may be another
RFC that obsoletes/updates RFC1812. In the hypothetical case you have a new
RFC1812' that does not mandate ICMP, there may be another hypothetical new ICMP
doc as well.

regards,
suresh

---

From: Christian Huitema <[email-masked]>
Date: Mon, 9 Apr 2007 00:12:11 -0700

Microsoft just released a tool that may be interesting for this list:
http://www.microsoft.com/windows/using/tools/igd/default.mspx
The tool applies various tests against routers to check how they
implement NAT, UPNP, or support of various TCP options. It is based on
Microsoft's "home networking" requirements for XP and Vista. Arguably, a
later version could implement BEHAVE's requirement, when they are
published by the IETF.

-- Christian Huitema