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 15:48:27 -0700 (PDT)

Did we agree on the following for REQ-11?

REQ-11: Receipt of any sort of ICMP message MUST NOT destroy the NAT
        mapping.
     a) The NAT's default configuration SHOULD NOT filter ICMP messages
        based on their source IP address.
     b) It is RECOMMENDED that a NAT support ICMP Destination 
        Unreachable messages.
     c) The ICMP timeout SHOULD be greater than 2 seconds.

Or are people still questioning c), and if so what would be the
proposal.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Jul 2005 16:28:07 -0700 (PDT)

At 5:48 PM -0500 7/6/05, 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.
I disagree with such a short timeout. Why not 2 minutes (or shorter, 
only if the NAT's ICMP message buffer is running out of space)? If 
the ICMP responder is busy doing something else, and waits 2.1 
seconds, and the sender has thrown away the state, this would cause 
unexpected behavior.

If the 2 seconds is specified in the ICMP spec, that's fine; 
otherwise, we should stretch out as far as we can.

--Paul Hoffman, Director
--Cybersecurity Association
--www.cybersecurity.org

---

From: Saikat Guha <[email-masked]>
Date: Wed, 6 Jul 2005 16:39:10 -0700 (PDT)

> Or are people still questioning c), and if so what would be the

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
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 7 Jul 2005 05:24:03 -0700 (PDT)

You need to go read your draft. Below is what your draft says.

REQ-11: It is RECOMMENDED that a NAT support ICMP Destination
      Unreachable.
      a) The ICMP timeout SHOULD be greater than 2 seconds.

I propose moving the coverage on ICMP processing to the ICMP draft (or) adapt
the text in section 3.8 of the ford-behave-gen-01.txt.

cheers,
suresh

--- Francois Audet <audet@xxxxxxxxxx> wrote:

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

---

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

I think this is the backwards way of looking at this spec. This spec is not
how to implement a NAT, it is a set of assumptions that an application can
make about a NAT. Many NATs today do this timeout very short for "security
reasons" whatever those are. I'm not arguing this is good or bad. I'm
arguing that so far no one has presented a reason why an application would
need to assume a larger value than this and we know it is an issue with NATs
so why not ask for what applications need, not ask for things that might be
a good idea but we don't need, and not ask for things that will never happen
(such as default configuration of EF=I)

Cullen <as individual>

-----Original Message-----
From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Paul Hoffman
Sent: Thursday, July 07, 2005 1:28 AM
To: Francois Audet; ietf-behave@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt

>Or are people still questioning c), and if so what would be the

I disagree with such a short timeout. Why not 2 minutes (or shorter, only if
the NAT's ICMP message buffer is running out of space)? If the ICMP
responder is busy doing something else, and waits 2.1 seconds, and the
sender has thrown away the state, this would cause unexpected behavior.

If the 2 seconds is specified in the ICMP spec, that's fine; otherwise, we
should stretch out as far as we can.

--Paul Hoffman, Director

---

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

C does not say you need to use a timer, just that however you implement it,
under fairly normal assumptions this should happen (clearly it would not
happen if the NAT was say unplugged)

cullen, not as chair

-----Original Message-----
From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Francois Audet
Sent: Thursday, July 07, 2005 12:48 AM
To: ietf-behave@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Ietf-behave] FW: I-D ACTION:draft-ietf-behave-nat-udp-02.txt

Or are people still questioning c), and if so what would be the proposal.
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave