Subject: [Ietf-behave] Conflicting ICMP payload translation reqs: MUST vs. SHOULD

From: Saikat Guha <[email-masked]>
Date: Tue, 24 Oct 2006 17:45:40 -0500 (CDT) (envelope-from [email-masked])

UDP *RECOMMENDS* that ICMP payloads be translated and forwarded. From
draft-ietf-behave-nat-udp-08.txt:

        The NAT's default configuration SHOULD NOT filter ICMP messages
        based on their source IP address.  Such ICMP messages SHOULD be
        rewritten by the NAT (specifically the IP headers and the ICMP
        payload) and forwarded to the appropriate internal or external
        host.
        
ICMP *REQUIRES* that ICMP payloads be translated and forwarded. From
draft-ietf-behave-nat-icmp-01.txt:

        If the the NAT has active mapping for the embedded payload, then
        the NAT MUST do the following prior to forwarding the packet. 
        a) Revert the IP and transport headers of the embedded IP packet to
           their original form, using the matching mapping; and
    ...

TCP currently aligns itself with ICMP/MUST because receiving the ICMP
messages and being able to link them to the actual connection is
essential for path  MTU discovery.

From my reading of the documents, the requirements in ICMP/TCP and UDP
are in conflict.

Is there any particular UDP has a SHOULD and not a MUST? If so, should
the recommendation be narrowed only to UDP payloads inside ICMP packets?

-- 
Saikat
Attachment:
signature.asc

---

From: Fernando Gont <[email-masked]>
Date: Wed, 25 Oct 2006 00:09:29 -0500 (CDT) (envelope-from [email-masked])

At 19:45 24/10/2006, Saikat Guha wrote:

As a meta comment, I'd suggest that all the ICMP-related stuff be 
included only in the ICMP document, rather than spread it over three 
documents (ICMP, TCP, and UDP).

As for whether to rewrite the ICMP payload is a MUST or SHOULD, I'd 
vote for the "MUST".

Whether one likes it or not, ICMP is a signalling protocol that is 
part of the TCP/IP suite. You cannot just NAT the transport protocol, 
but kill the protocol that aids in signalling error conditions.

If anybody wants to get rid of ICMP, the one should get rid of it for 
"non-NATed" traffic, and only then the NAT-related specs should follow.

Just my two cents,

--
Fernando Gont
e-mail: fernando@xxxxxxxxxxx || fgont@xxxxxxx
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 25 Oct 2006 08:48:33 -0500 (CDT) (envelope-from [email-masked])

I full agree with Fernando. I do believe, all normative requirements related to
ICMP should be in the ICMP document and not spread across multiple documents.
Repeating in multiple drafts in different words is prone to language
interpretation problems. I also believe, a NAT MUST rewrite the payload.

As for the requirement in UDP draft (soon to be an RFC) - During the WG last
call when this issue was brought up, folks wanted to leave the requirement in
there so the publication is not delayed (I dont recall discussig the SHOULD vs
MUST for the requirement, however.).

This exception for the UDP draft is understandable. However, the requirement
shoudlnt have to be repeated in the TCP draft. TCP draft could simply refer the
requirement in the ICMP draft rather than list as a distinct TCP requirement.

My 2c.

regards,
suresh  

--- Fernando Gont <fernando@xxxxxxxxxxx> wrote:

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 25 Oct 2006 10:03:39 -0500 (CDT) (envelope-from [email-masked])

I'm just watching out for the poor Gen-ART reviewer who gets the last 
document in this string...

- Is it the intention that the ICMP document UPDATEs the UDP document, in 
the RFC Editor sense of the word?

- Is it the intention that the TCP document updates the ICMP document?

Given that the UDP draft is in the RFC Editor Queue, and the ICMP and TCP 
documents are not even assigned to a shepherding AD in the tracker yet, your 
best path forward really may be to issue UDP, UPDATE it with ICMP, and refer 
to ICMP for the ICMP requirements supporting TCP... assuming that the TCP 
draft doesn't pass the ICMP draft in the chute.

This does tend to make our archival document series denser and less 
implementer-friendly, but sometimes "good enough" is the best we can do.

If I got this hand grenade over the review transom, I'd definitely be asking 
this at IETF Last Call time, and probably at IESG Telechat time as well, so 
thinking about this now is probably better than thinking about it some other 
times...

Thanks,

Spencer

I full agree with Fernando. I do believe, all normative requirements 
related to
ICMP should be in the ICMP document and not spread across multiple 
documents.

As for the requirement in UDP draft (soon to be an RFC) - During the WG 
last
call when this issue was brought up, folks wanted to leave the requirement 
in
there so the publication is not delayed (I dont recall discussig the 
SHOULD vs

This exception for the UDP draft is understandable. However, the 
requirement
shoudlnt have to be repeated in the TCP draft. TCP draft could simply 
refer the
requirement in the ICMP draft rather than list as a distinct TCP 
requirement.

My 2c.

regards,
suresh

Just my two cents,

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 25 Oct 2006 10:49:29 -0500 (CDT) (envelope-from [email-masked])

Spencer Dawkins wrote:

> Given that the UDP draft is in the RFC Editor Queue, and the 
> ICMP and TCP documents are not even assigned to a shepherding 
> AD in the tracker yet, your best path forward really may be 
> to issue UDP, UPDATE it with ICMP, and refer to ICMP for 
> the ICMP requirements supporting TCP... assuming that the TCP 

Yes, I agree that's what we should do.  ICMP's text can 
clearly indicate this one UDP requirement that it's updating
from Should to Must.

-d

---

From: Christian Huitema <[email-masked]>
Date: Wed, 25 Oct 2006 13:43:01 -0500 (CDT) (envelope-from [email-masked])

> clearly indicate this one UDP requirement that it's updating

I do not agree with the rationale for this argument. We can see two
different set of problems, and they have different solutions:

1) Specify how the NAT will translate ICMP packets, either incoming or
outgoing: this belongs logically to the ICMP specification.

2) Specify how the translation state for another protocol is affected by
the reception of UDP packets: this belongs logically in the
specification of that protocol.

For example, the reaction of TCP to "soft errors" or "hard errors"
belongs in TCP, not in ICMP.

-- Christian Huitema

---

From: Saikat Guha <[email-masked]>
Date: Wed, 25 Oct 2006 13:51:01 -0500 (CDT) (envelope-from [email-masked])

> belongs in TCP, not in ICMP.

I second this argument, which incidentally, was what I understood to be
the outcome of IETF65:
- BEHAVE-ICMP should be responsible for ONLY ICMP requests and responses
- BEHAVE-[proto] should be responsible for ICMP messages earned from the
  network in response to [proto] packets.

-- 
Saikat
Attachment:
signature.asc

---

From: Christian Huitema <[email-masked]>
Date: Wed, 25 Oct 2006 15:23:41 -0500 (CDT) (envelope-from [email-masked])

> 2) Specify how the translation state for another protocol is affected
> by the reception of UDP packets: this belongs logically in the
                      ^^^ => I really meant ICMP. Sorry.

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 26 Oct 2006 08:01:22 -0500 (CDT) (envelope-from [email-masked])

> outgoing: this belongs logically to the ICMP specification.

[suresh] Right, We both agree on this. This directly addresses the comment from
Saikat. The specific comment from Saikat was to do with a) MUST/SHOULD
requirement on ICMP payload translation. b) TCP draft alignment with the MUST
requirement in the ICMP draft.

As you say, I too believe, the normative text for ICMP payload translation
requirement belongs in the ICMP draft. Req-4 and Req-5 of the ICMP draft
specify this.

I just looked up the TCP and UDP drafts. Neither of the drafts specify this
language in the Requirements text. This language is mentioned only in the text
preceding a requirement. In the UDP draft, this is mentioned in section 9,
preceding REQ-12. In the TCP draft, this is only mentioned in the text
preceding REQ-9 in section 7.3. Neither of the drafts mention it in the actual
requirements.

Given that the normative text only appears in the descriptive text and not in
the requirements in the UDP draft(soon-to-be RFC), it is *not* likely to cause
much confusion. People usually pay attention to the final requirements text. As
for the TCP draft, it is simply a matter of refering the ICMP draft
requirements in the text, instead of stating in absolute terms.

> belongs in TCP, not in ICMP.

[suresh] This comment, I believe, refers to ICMP error messages effecting the
state of  NAT Sessions pertaining to embedded packets. This was not the subject
of Saikat's e-mail, as far as I can tell. But, you do bring up a good point
here. This is another area where there is overlap in requiremens between ICMP,
UDP and TCP drafts.

The ICMP states this requirement as follows. 
   REQ-6: While processing an ICMP error packet, a NAT device MUST NOT
   refresh or delete the NAT Session that pertains to the embedded
   payload within the ICMP error packet.
 
The text is neutral to the transport protocol of the embedded packet. SO, it
seemed to make sense to keep the normative text in the ICMP draft. However, if
you believe, the text belongs in each of the protocol drafts, I am willing to
go with that. Thanks.

regards,
suresh