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

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

ISSUE-2
 2. NAT MUST NOT modify ICMP 'type' values.

  Saikat asked if anyone was familiar with a NAT that actually had
  this behavior, and if we should mention this in the draft.

  Magnus said perhaps it should stay in the draft.

  Cullen said he hadn't seen a NAT that does this.

RESOLUTION: REQ-4 and REQ-5 of the ICMP describe the requirements for
translationg ICMP error packets inbound and outbound as follows. NAT is
mandated to not translate ICMP error type or ICMP code.

   REQ-4: If a NAT device receives an ICMP error packet from external
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP error packet. If the
   the NAT has active mapping for the embedded payload, then the NAT
   MUST transparently forward the ICMP error message, without modifying
   the ICMP error type or code as follows.
   a) The NAT MUST revert the IP and transport headers of the embedded
   IP packet to their original form, using the matching mapping.  
   b) The NAT device MUST modify the destination IP address of the
   outer IP header to be same as the source IP address of the embedded
   IP packet after the translation. 
   c) Lastly, the NAT MUST update the IP and ICMP checksums in the
   outer headers to reflect the above changes.

   REQ-5: If a NAT device receives an ICMP error packet from private
   realm, and the NAT does not have an active mapping for the embedded
   payload, the NAT SHOULD silently drop the ICMP error packet. If the
   the NAT has active mapping for the embedded payload, then the NAT
   MUST transparently forward the ICMP error message, without modifying
   the ICMP error type or code as follows.
   a) The NAT MUST revert the IP and transport headers of the embedded
   IP packet to their original form, using the matching mapping.  
   b) If the NAT device has active mapping for the ICMP error packet
   originator, the NAT MUST translate the source IP address of the
   ICMP error packet with the public IP address in the mapping. 
   Otherwise, the NAT MUST translate the source IP address of the ICMP
   error packet with its own public IP address. 
   c) Lastly, the NAT MUST update the IP and ICMP checksums in the
   outer headers to reflect the above changes.

---

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

>    IP packet to their original form, using the matching mapping.  

It should be made clear that the 'mapping' here refers to the mapping
used by the TCP or UDP protocol modules and not the ICMP mapping (the
ICMP mapping is for ICMP request-response packets only). Also, the
'exteral realm' business doesn't specify what happens to ICMP errors on
hairpinned UDP/TCP connection. Perhaps something along the lines of:

REQ-x: If a NAT device receives an ICMP error packet, it must use the
mapping that matches the embedded packet for translating the ICMP error.
If such a mapping does not exist, the NAT SHOULD silently drop the ICMP
error packet. If the mapping exists, the NAT MUST transparently forward
the ICMP error.
a) A NAT must translate both the other header and the embedded packet
according to the mapping.

>    outer headers to reflect the above changes.

Requirement b) and c) seem out of place -- they read like pseudo-code
for a NAT implementation written in prose. Unless the idea is to give a
complete pseudo-code implementation of a NAT, they can likely be dropped
in favor of the principles behind them. 

>    outer headers to reflect the above changes.

See the proposed REQ-x above. It subsumes this case.

-- 
Saikat
Attachment:
signature.asc

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 28 Jun 2006 08:19:12 -0700 (PDT)

--- Saikat Guha <saikat@xxxxxxxxxxxxxx> wrote:

> ICMP mapping is for ICMP request-response packets only). 

[suresh] The text "active mapping for the embedded payload" refers eactly that.
If the embedded payload is a TCP/UDP packet, the text refers the active mapping
for the TCP/UDP packet. If the embedded payload is an ICMP query packet, the
text refers the active mapping for the ICMP query packet. No matter what the
embedded packet is, the text refers the active mapping for the embedded packet.

>                                                          Also, the
> hairpinned UDP/TCP connection. 

[suresh] Hairpinning is required for TCP/UDP flows. So, when a NAT supports
hairpining for a TCP/UDP flow, Req-5a enforces translation for the embedded
TCP/UDP packet automagically.

As for Hairpinning with regard to ICMP error messages, NAT sees this as an ICMP
error message coming from a private realm. So, Req-5 addresses the hairpinning
for ICMP error messages.

>                                Perhaps something along the lines of:
> 
[suresh] Please see my note above.

> in favor of the principles behind them. 
[suresh] The three subsection of Req-4 and Req-5 identify specfic requirements.
Req-4a and Req-5a specify the requirement on how the embedded payload should be
translated. Req-4b and Req-5b specify how the outer IP adresses must be
selected for translation. See sections 4.2.1 and  4.2.2 for details leading up
to Req-4b and 5b. Req-4c and Req-5c specify that the IP/ICMP checksums should
be updated to reflect the previous two changes (i.e.,4a+4b or 5a+5b). 

Potentially, Req-4c and Req-5c could be dropped, as they are assumed to be done
by all NAT devices. However, when a NAT does not update ICMP checksum, many end
host stacks woudl drop the ICMP error packets. Refer Fernano's draft. Hence,
REQ-4c and REQ-5c are included to reinforce the requirement to update ICMP
checksum. 

> See the proposed REQ-x above. It subsumes this case.
[suresh] Please see my notes above.

cheers,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 5 Jul 2006 06:41:48 -0700 (PDT)

Folks,

I will make an explicit mention of the mandatory requirement to support ICMP
error messages for "hairpinned flows". 

I could do this by including this statement within Req-5. Thanks.

cheers,
suresh

--- Pyda Srisuresh <srisuresh@xxxxxxxxx> wrote:

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