Subject: [Ietf-behave] Issue 1 - ICMP draft issues from the IETF 65 WG meeting

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 24 Jun 2006 07:01:32 -0700 (PDT)

ISSUE-1
  1. PING sends an echo request, next PING goes to a different
     mapping; what default timeout should exist for the mappings?

  Magnus - should give consideration to using Maximum Segment
  Lifetime.

RESOLUTION: REQ-2 of the ICMP draft states the timer requirement as follows.
ICMP query applications (such as ping and ICMP traceroute) are request-response
kind and often complete within a few seconds. S0, 60 secs was set as the bar
for ICMP query session timeout.

   REQ-2: An ICMP Query session mapping timer MUST NOT expire in less
   than 60 seconds.
   a) The value of NAT ICMP mapping timer MAY be configurable.

---

From: Saikat Guha <[email-masked]>
Date: Mon, 26 Jun 2006 08:57:45 -0700 (PDT)

>      mapping; what default timeout should exist for the mappings?

Does this affect NATs with only one external IP? There is no notion 
of an ICMP "port" so the mapping is only between the external IP and 
the internal IP.

For NATs with multiple external IPs, the requirement can be to enforce
that mapping behavior is endpoint address independent i.e. if the NAT
allocates a mapping (picks an external address) for an outbound ICMP
from an internal address, then it must continue to use that same
external address for subsequent ping or other ICMPs until the mapping
expires.

REQ-x: A NAT must have endpoint independent mapping behavior for ICMP
       requests. This requirement applies only to NATs that have 
       multiple external IP addresses.

>    a) The value of NAT ICMP mapping timer MAY be configurable. 

In light of the recent UDP changes that allows "well-known"
request-response protocols to have a shorter timeout. Also, the 60s is
not consistent with the MSL values in other RFC. perhaps something along
the lines of:

REQ-x: MUST NOT be less than 60s unless a) applies.
       a) Can be shorter for well-known request-response types
       b) SHOULD NOT be less than 4min

-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 28 Jun 2006 07:04:53 -0700 (PDT)

> of an ICMP "port" so the mapping is only between the external IP and 
[suresh] "Query Id" in ICMP Queries is the equivalent of ports in TCP/UDP
flows. Just as a NAT provides port mapping for TCP/UDP plows, the NAT also
provides Query ID mapping for ICMP Query flows.

>        multiple external IP addresses.

[suresh] When a NAT has a single external address, the NAT does port mapping
for TCP/UDP flows and Query ID mapping for ICMP flows (NAPT). When a NAT has
multiple external addresses, the NAT does address mapping for TCP/UDP flows and
ICMP Query flows (Basic NAT). In the latter case, the ports and ICMP query IDs
are not modified. Only the IP address is translated. As you can see, the
analogy is identical to TCP/UDP flows and ICMP Query flows. Hence, the text
used in the ICMP draft is similar to that of TCP and UDP drafts.

>        b) SHOULD NOT be less than 4min
[suresh] ICMP Query messages are meant to be used only in the context of
request-response type of applications. Are you saying you like to draw
distinction between "well-known request-response" type applications and "other
request-response" type applications? I dont believe that is necessity.

cheers,
suresh

---

From: Saikat Guha <[email-masked]>
Date: Wed, 28 Jun 2006 08:58:09 -0700 (PDT)

> provides Query ID mapping for ICMP Query flows.

Right. The ICMP mapping only makes sense for ICMP request-response
exchanges, and those all have the query identifier. Agreed that the
concern holds for NATs with single IP addresses as well and maps onto
the TCP/UDP analog of ports to some extent.

There is a difference in TCP/UDP ports and ICMP request-response though.

TCP/UDP ports are important to the destination -- the port is stored at
the application level (think FTP), communicated to other endpoints
(think bittorrent) etc. That is why the NAT must have endpoint
independent mapping for TCP/UDP; so that if the application at B conveys
A's external port (as seen by B) to C, then C can expect to receive a
packet from A from that external port and no other. That is the
justification behind endpoint independent mapping.

I am not aware of any ICMP applications that have similar requirements.

Ping, traceroute, etc. simply echo back the identifier in the response
-- as a mechanism to demultiplex the response. It doesn't matter, AFAIK,
if different ping packets arrive at the (same or different) destination
with different identifiers even if the source use the same identifier so
long as the response is translated back appropriately. And now that I
think about it, back to your original question, I don't see any problem
if the "next ping goes to a different mapping" .. even if the next ping
gets assigned a whole new IP address or identifier. 

Are there any P2P (or otherwise) applications that require subsequent
ICMP packets sent from the same source (IP/identifier) to appear to come
from the same external address/identifier? 

Suggest: Either removing REQ-1 (because it doesn't affect applications)
or upgrading REQ-1 to a MUST (if we want to be pedantic)

> request-response" type applications? I dont believe that is necessity.

Requiring 60s for all req-resp (especially ping) is just asking for a
DoS attack (an unintentional one at that). A simple application that
sends one ping packet to every box on a subnet to check for liveness
would quickly DoS the NAT:

 for i in $(seq 0 255); ping -c 1 10.10.1.$i; done
    or
 while true; do ping -c 3 A; ping -c 3 B; sleep 1; done

Both potentially useful shell-script that could ICMP DoS a NAT. TCP/UDP
applications typically have much smaller fanout -- the UDP equivalent of
the above would likely be a DoS attack, the ICMP version is likely to be
diagnostic and legitimate for the most part.

Suggest: Allow NAT to close mapping as soon as ping-response is received

-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Mon, 3 Jul 2006 07:44:16 -0700 (PDT)

Hi Saikat,

Apologies for my delayed response. Please see my comments in line.

cheers,
suresh

> the TCP/UDP analog of ports to some extent.
[suresh] OK. We are in agreement so far.

> I am not aware of any ICMP applications that have similar requirements.
[suresh] When NAT was originally conceived or when the initial NAT RFCs were
published, majority of the applications were client-server based. Port-binding
was not a big issue. A number of client-server apps just worked with symmetric
NATs. Now, we know of many TCP/UDP applications can have multiple peers and
they could send and receive connections simultaneously from/to remote peers.
So, we know port binding is an issue and we are promoting Port binding now.

Likewise, there arent any ICMP applications today (that I know of) that talk
with more than one node simultaneously. NATs currently assign different Query
ID mapping for each new external host. However, ICMP applications  of the
future could change. ICMP applications could be interfacing with multiple peers
simultaneously using the same query ID. In such a case, the applications would 
desire NATs to retain the same Query ID mapping across all remote nodes the
originating host is interfacing with. 

SO, keeping this in view, REQ-1a recommends NATs to make the Query ID mapping
external host independent. RFC 792 says the following about Query Identifier
field. The defintion does not prohibit a sender from using the same Query
Identifier to communicate with multiple target nodes. 

      The identifier and sequence number may be used by the echo sender
      to aid in matching the replies with the echo requests.  For
      example, the identifier might be used like a port in TCP or UDP to
      identify a session, and the sequence number might be incremented
      on each echo request sent.  The echoer returns these same values
      in the echo reply.

> gets assigned a whole new IP address or identifier. 

[suresh] Please see my comment above. For independent client-server pings, what
you say is true. But, this is not appliable to applications that reuse the same
mesage identifier with multiple external nodes.

> or upgrading REQ-1 to a MUST (if we want to be pedantic)
[suresh] REQ-1a is not made a MUST because existing ICMP apps do not requie it.

REQ-1a is made a SHOULD, so fully compliant NATs would make query ID mapping
end host independent.

> Suggest: Allow NAT to close mapping as soon as ping-response is received
[suresh] Right, DoS attacks are possible with all protocols, including TCP, UDP
and ICMP. What you suggest above is a way to defend. Not the only way. It is
not our objective to tell NAT vendors how they should defend a particular DoS
attack. As I recall, it was decided in one of the WG meetings that requirements
concerning DoS attacks is considered out of scope of the Behave drafts. SO, the
the UDP and TCP drafts do not mention requirement to defend against Dos
attacks. Neither does the ICMP draft.

cheers,
suresh