Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt

From: "Francois Audet" <[email-masked]>
Date: Wed, 6 Jul 2005 17:13:36 -0700 (PDT)

OK, I don't understand the 2s timer either.

I'm hearing a bunch of votes for removing requirement c, and I don't
have
objections.

Dan/Cullen, I think this requirement came from you. Objections to
removing it
from the UDP draft?

(Presumable some ICMP document would clarify further any timers
requirement
for this, as per Saikat's suggestion below).

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Saikat Guha
> Sent: Wednesday, July 06, 2005 16:39
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Ietf-behave] FW: I-D 
> ACTION:draft-ietf-behave-nat-udp-02.txt
> 
> 
> On Wed, 2005-07-06 at 17:48 -0500, Francois Audet wrote:
> >      c) The ICMP timeout SHOULD be greater than 2 seconds.
> > 
> > Or are people still questioning c), and if so what would be the 
> > proposal.
> 
> Perhaps I am just being obtuse, but I really don't understand 
> requirement c). See my point #10 in 
> http://list.sipfoundry.org/archive/ietf-behave/msg00759.html
> 
> In any event, I agree with Paul that there should be no timer 
> unless an RFC for the ICMP protocol defines one for the 
> particular case ... and I do not know what the particular 
> timer is for so I cannot say either yay or nay.
> 
> Some timers that might be relevant based on intent:
> 
> Intent #1: Handling an inbound ICMP packet in response to an 
> outbound TCP/UDP packet -- The maximum time an in-flight 
> packet is considered alive is 2 minutes (RFC 1122). So it may 
> take at most 4 minutes for can ICMP to come back. ... But the 
> encapsulated IP packet inside the ICMP will have all the data 
> needed to route the packet (as long as the mapping is alive) 
> ... so there is no point specifying the timeout if this is the intent.
> 
> Intent #2: Preventing packet storms; ICMP rate-limiting -- 
> RFC 2521 says ICMP's should be rate limited but the timer is 
> "left to the implementor's discretion". If this is the 
> intent, I'd suggest not specifying a timer value.
> 
> Intent #3: Handling inbound ICMP's that do not have an 
> encapsulated IP packet to help routing, such as ICMP Echo 
> Response -- If this is the intent, it needs to be made clear. 
> Also, by the same logic as #1, RFC 1122 would say that an 
> ICMP Echo Response may be received within at most 4 minutes; 
> so that should be the recommended value of the timer. That 
> said, reiterating Paul's point -- unless the NAT is low on 
> available "ICMP mappings", it should not expire any ICMP 
> mapping. If it is low, then it should expire ICMP mappings 
> that have been open for more than 4 minutes. If that doesn't 
> free up any mappings, then it should reject the new ICMP 
> packet -- to prevent an insider from DoS'ing the NAT.
> 
> I think Intent #3 makes most sense logically; and if we are 
> going to have a separate ICMP draft (as per the charter), 
> thats where this issue should go. But if we are not, then the 
> intent should be made more clear. 
> 
> -- 
> Saikat
>

---

From: "Cullen Jennings" <[email-masked]>
Date: Sun, 31 Jul 2005 03:31:28 -0700 (PDT)

I implementer implement it as 10 ms, then path MTU discovery will not work
on any path longer than 10 ms from the NAT.

I'm not sure I have seen any implementation that were too short so I will
have to think about if I actually care if it is there or not.

-----Original Message-----
From: Francois Audet [mailto:audet@xxxxxxxxxx]
Sent: Thursday, July 07, 2005 2:14 AM
To: ietf-behave@xxxxxxxxxxxxxxxxxxx; dwing@xxxxxxxxx; Cullen Jennings
Cc: Saikat Guha
Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt

I'm hearing a bunch of votes for removing requirement c, and I don't have
objections.

Dan/Cullen, I think this requirement came from you. Objections to removing
it from the UDP draft?

(Presumable some ICMP document would clarify further any timers requirement
for this, as per Saikat's suggestion below).

> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Saikat
> Guha
> In any event, I agree with Paul that there should be no timer unless
> an RFC for the ICMP protocol defines one for the particular case ...
> and I do not know what the particular timer is for so I cannot say
> either yay or nay.
>
> Intent #1: Handling an inbound ICMP packet in response to an outbound
> TCP/UDP packet -- The maximum time an in-flight packet is considered
> alive is 2 minutes (RFC 1122). So it may take at most 4 minutes for
> can ICMP to come back. ... But the encapsulated IP packet inside the
> ICMP will have all the data needed to route the packet (as long as the
> mapping is alive) ... so there is no point specifying the timeout if
> this is the intent.
>
> Intent #2: Preventing packet storms; ICMP rate-limiting -- RFC 2521
> says ICMP's should be rate limited but the timer is "left to the
> implementor's discretion". If this is the intent, I'd suggest not
> specifying a timer value.
>
> Intent #3: Handling inbound ICMP's that do not have an encapsulated IP
> packet to help routing, such as ICMP Echo Response -- If this is the
> intent, it needs to be made clear.
> Also, by the same logic as #1, RFC 1122 would say that an ICMP Echo
> Response may be received within at most 4 minutes; so that should be
> the recommended value of the timer. That said, reiterating Paul's
> point -- unless the NAT is low on available "ICMP mappings", it should
> not expire any ICMP mapping. If it is low, then it should expire ICMP
> mappings that have been open for more than 4 minutes. If that doesn't
> free up any mappings, then it should reject the new ICMP packet -- to
> prevent an insider from DoS'ing the NAT.
>
> I think Intent #3 makes most sense logically; and if we are going to
> have a separate ICMP draft (as per the charter), thats where this
> issue should go. But if we are not, then the intent should be made
> more clear.
>
> --
> Saikat
>