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

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 8 Jul 2005 08:50:42 -0700 (PDT)

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Saikat Guha
> Sent: Wednesday, July 06, 2005 7:39 PM
> 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.
> 

Your opinion of not having a timer just for this particular case or in
general?
In any case, I think you are suggesting how this should be implemented
rather than just stating the requirements. The reason why I  say that is
you seem to have implied above that NAT boxes should have a protocol
specific mapping space that it should manage. I thought the intention of
this WG is to specify the behavior of NAT so that it is consistent. With
this suggestion of removing mappings based on resource usage per
protocol, I see that different vendors could allocate different size
mapping space for each protocol based on the available memory in their
boxes. This cause inconsistent behavior. Now if I am a NAT vendor and if
I don't have an implementation of per protocol mapping space any
considerable changes to the implementation simply won't happen. As you
have rightly pointed out in an earlier thread,

"If vendors cannot stay "fully compliant" without implementing this one
item with a wishy-washy justification, they might as well balk and stop
following any of the RECOMMENDED parts since they cannot be fully
compliant anyway; which would be a complete disaster."

The above discussion on not having timeout based mechanisms fit right in
the above category.

Senthil

> 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: Saikat Guha <[email-masked]>
Date: Fri, 8 Jul 2005 14:01:52 -0700 (PDT)

> Your opinion of not having a timer just for this particular case or in

In general, if the RFCs specify the timer then mention it; if they don't
then not make one up unless it avoids something important. In my book,
DoS is important, long-term resource depletion is important, short-term
resource depletion is not. In particular, I'd say something like:

REQ-11 c) A NAT SHOULD translate and forward ICMP responses received
within 4 minutes of sending the ICMP request to the internal host that
sent the request.

since RFC 1122 gives timer values. But since no RFC mentions any sort of
UDP keepalive, I'd like to say:

REQ-5: A NAT UDP mapping MUST NOT be reclaimed unless the NAT is unable
    to allocate a mapping for a new session.
      a) A NAT UDP mapping MUST NOT be reclaimed within 2 minutes of a
         packet traversing the NAT associated with that mapping.

Perhaps with fewer negatives, but the main requirement here is that
mappings stay active as long as possible. Reclaim only to avoid long-
term depletion, not short-term. The 2 minute is something we add for DoS
protection (2 based on consensus on the last version). The additional 5
minutes recommendation was arbitrary anyway. 

-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Sun, 10 Jul 2005 02:10:22 -0700 (PDT)

Saikat,

This is not what NAT devices do. 

NAT devices donot time latencies (as you seem to suggest in REQ-11 proposal). I
would NOT support this proposal.

NAT devices use idle timeouts to timeout TCP/UDP sessions and associated
Bindings. Making the idle timeouts for UDP Sessions dynamic has serious
ramificatiosn on the resource usage and availability, not to mention the delays
  in creating new NAT Sessions. I would NOT support your proposal for REQ-5.

cheers,
suresh

--- Saikat Guha <sg266@xxxxxxxxxxx> wrote:

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

---

From: Saikat Guha <[email-masked]>
Date: Mon, 11 Jul 2005 11:32:12 -0700 (PDT)

On Sun, 2005-07-10 at 02:10 -0700, Pyda Srisuresh wrote:
> NAT devices do not time latencies [...] NAT devices use idle timeouts

"idle timeout" is not defined for protocols where only one packet is
ever sent or received, as is the case with many ICMP requests.

> Making the idle timeouts for UDP Sessions dynamic has serious
> ramificatiosn on the resource usage and availability, 

I do not agree. If the NAT has space to allocate new mappings and yet
expires existing ones prematurely based on some arbitrary timer in
anticipation of new connections that may or may not arrive, then the NAT
is _wasting_ resources. In the extreme case, there is not reason why a
single host behind a NAT (no other internal hosts) running a single
application (no other network activity) has to ever send a 'keep-alive'.
I hate to use analogies, but what you propose is like having a coffee
house throw someone out just because they have not been drinking coffee
for 5 minutes even though the coffee house is empty. What I am
suggesting is that they be thrown out only when the coffee house is full
(or close to full) and there are customers waiting for a seat.

> not to mention the delays
>   in creating new NAT Sessions.

In the existing proposal, a NAT silently expires a mapping without
sending any ICMP etc; expiry is immediate -- there is no proposed
TIMED_WAIT for the port after the mapping is expired. The same behavior
can be preserved where the NAT silently and instantaneously expires the
mapping when it is low on resources (as opposed to when an idle timer
expires). 

-- 
Saikat

Attachment:
signature.asc