Subject: [Ietf-behave] Question about ICMP scope and how we split it over documents

From: Cullen Jennings <[email-masked]>
Date: Fri, 7 Jul 2006 22:24:10 -0700 (PDT)

Some folk were discussing the ICMP draft on a call the other day and  
it came up that there was some lack of agreement about the overall  
scope. We wanted to sort out the WG as a whole view of the scope  
here. I'll try to describe the two views - no doubt I will get the  
words less than perfect but hopefully I will get them close enough. S

o the questions is about which documents get different parts of the  
ICMP behavior defined in them. Everyone on the call agreed that the  
scope was limited to describing the overall behaviors of NATs such  
that NATs would, as much as possible and still be deployable NATs,  
not break applications or protocols that used ICMP and define the NAT  
handling of ICMP such that the NATs did not have non deterministic  
behavior from the point of view of the applications. Everyone also  
agreed that the draft-ietf-behave-nat-icmp draft should define the  
behavior of NAT when handling ICMP requests and also handing ICMP  
responses that were generated by hosts in response to these ICMP  
requests - clearly things like ICMP ping is in the scope of the  
behave-nat-icmp draft. Where everyone did not agree had to do with  
the question of which document defines the handling of ICMP messages  
that were generated in response to messages sent by some other  
protocol type such as UDP or TCP.

View 1) This view was that the ICMP handling messages caused by  
protocol X should be described in the behave document for protocol X.  
The argument for this view was more or less that long ago we had  
tried to do this all in an ICMP document, it looked confusing to  
implementers to have them in separate documents and the WG had  
decided to move that part of the ICMP handling into the protocol  
documents (such as UDP and TCP).

View 2) Did not remember a decision to organize the WG documents that  
way. They were uncomfortable with that organization. I'm not sure  
anyone actually said it on the call but I expect the proponents of  
this view would point out that having the stuff you need for ICMP  
spread across multiple documents seems like a bad idea.

None of the people on the call are big fans of going back and  
remaking decisions that are already made - So the question is, what  
are others people recollection of our plan here? Was a decision made  
on this?

Thanks,
Cullen <with my individual contributor hat on>

---

From: Pyda Srisuresh <[email-masked]>
Date: Sat, 8 Jul 2006 09:15:04 -0700 (PDT)

> words less than perfect but hopefully I will get them close enough. S

[suresh] Thanks, Cullen. 

> protocol type such as UDP or TCP.

[suresh] Your comment is whether processing of ICMP error messages is in the
scope of ICMP draft or not. Well, we did discuss this specific issue
extensively during the draft review with the WG chair. You were also on all the
e-mails.  The conclusion of the discussion was to make ICMP error hadling text
protocol agnostic as in REQ-4 and REQ-5 (stated below,for ease of reference). 

The main body of the text in REQ-4 and REQ-5 refers to looking up the embedded
payload amongst active mappings, no matter what protocol or application the
payload belongs to. Req-4a and Req-5a says that NAT MUST revert the embedded IP
packet to its original form, using the matching mapping. Once again, this is
completely protocol agnostic. 

   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.

> spread across multiple documents seems like a bad idea.

[suresh] Yes, I do believe, it is a bad idea to repeat ICMP error handling in
protocol specific documents. ICMP error handliong as described in REQ-4 and
REQ-5 in the ICMP draft is protocol agnostic and applies to all protocols. 

> are others people recollection of our plan here? Was a decision made  

[suresh] Cullen - This is not the question of who recalls what from the past.
We have the ICMP draft as WG document, for the first time, now. Let us review
what should be in the scope of this document and whether the document is
covering material that is protocol specific.

The specific issue you raise apparantly did come up during the last WG meeting.
Dan had specifically raised this point with me during the internal draft
review. We agreed the initial wording that was used (ether in the presentation
or in earlier versions of the draft) was the teh cause of confusion. So, we
fixed the the wording in REQ-4 and REQ-5  such that such that they are prorocol
agnostic.

I believe, the questions are really the following.
a) IS ICMP error message handling within the scope of the ICMP draft? 
b) Are any of the requirements in the ICMP draft protocol specific?

Thanks.

regards,
suresh

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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 10 Jul 2006 21:25:07 -0700 (PDT)

On Jul 8, 2006, at 12:15 PM, Pyda Srisuresh wrote:

[suresh] Thanks, Cullen.

o the questions is about which documents get different parts of the
ICMP behavior defined in them. Everyone on the call agreed that the
scope was limited to describing the overall behaviors of NATs such
that NATs would, as much as possible and still be deployable NATs,
not break applications or protocols that used ICMP and define the NAT
handling of ICMP such that the NATs did not have non deterministic
behavior from the point of view of the applications. Everyone also
agreed that the draft-ietf-behave-nat-icmp draft should define the
behavior of NAT when handling ICMP requests and also handing ICMP
responses that were generated by hosts in response to these ICMP
requests - clearly things like ICMP ping is in the scope of the
behave-nat-icmp draft. Where everyone did not agree had to do with
the question of which document defines the handling of ICMP messages
that were generated in response to messages sent by some other
protocol type such as UDP or TCP.
[suresh] Your comment is whether processing of ICMP error messages  
is in the
scope of ICMP draft or not. Well, we did discuss this specific issue
extensively during the draft review with the WG chair. You were  
also on all the
e-mails.  The conclusion of the discussion was to make ICMP error  
hadling text
protocol agnostic as in REQ-4 and REQ-5 (stated below,for ease of  
reference).
Actually, I seem to recall that I was one of the WG chairs back then  
and that I pointed out the same thing back then.

But let's get clear about what we are talking about here - do you  
want to remove the ICMP handling out of the UDP document and move it  
to the ICMP document? I assure you many people outside behave  will  
think that defining it in two places is a bad idea. What do you want?

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 11 Jul 2006 08:09:00 -0700 (PDT)

> and that I pointed out the same thing back then.
[suresh] If you did, that is good. Can you you refer me to the e-mail where you
did? Assuming you did or you intended to do this, are you saying that you are
in agreement that ICMP  error handling text in the ICMP draft (as done in REQ-4
and REQ-5) is protocol agnostic? Do you also agree that such a protocol
agnostic text concerning ICMP error message handling is within the scope of the
ICMP draft?

> But let's get clear about what we are talking about here - do you  

[suresh] Right. That is a good idea. Let me explain what my understandig is and
how I gathered this.

Your original e-mail said the following - "Where everyone did not agree had to
do with the question of which document defines the handling of ICMP messages
that were generated in response to messages sent by some other protocol type
such as UDP or TCP."

By "ICMP messages that were generated in response to messages sent by some
other protocol type such as UDP or TCP", I assumed you were refering to ICMP
error messages. SO, my understanding is that this thread is about handling of
ICMP error messages and whether the handling of ICMP error messages is within
the scope of the ICMP draft. REQ-4 and REQ-5 of the ICMP draft address the core
of ICMP error handling. Hence, my response as above.

Now, what did you mean to talk about? It would help, if you can be specific
about the exact requirements that you want to talk about. I was on the same
call with you, I read your e-mail. Yet, it is not clear to me what you want to
talk about. 

> think that defining it in two places is a bad idea. What do you want?

[suresh]  This thread is not about removing any requirements out of UDP, AFAIK.
I certainly am not suggesting that at this time. I suggested removing the
overlapping requirements out of the UDP draft during the IESG review of the UDP
draft. But, UDP review was complete. A decision was made to keep the
requirements within the UDP. Let us move on.

Now, are you suggesting the opposite - To remove overlapping requirements from
the ICMP, now that UDP is on its way to becoming an RFC? That would be a BAD
thing to do. Just because we let go of the ICMP error overlap in UDP, doesnt
mean that we remove the ICMP error requirements from the ICMP draft where it
actually belongs. Specifically, I believe, this refers to REQ-6 and REQ-8.
REQ-6 and REQ-8 are well within the scope of ICMP draft. These requirements are
protocol agnostic and applies to all IP protocols.   

REQ-6 and REQ-8 of the ICMP draft:

   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.

   REQ-8: A NAT device MUST conform to RFC 1812 in IP packet handling.
   Below are specific instances where a NAT device MUST conform to 
   RFC 1812.
   a) If DF bit is set on a transit IP packet and the NAT
   device cannot forward the packet without fragmentation, the
   NAT device MUST send a "Packet too big" ICMP message (ICMP
   type 3, Code 4) with a suggested MTU back to the sender and
   drop the original IP packet.
   b) A NAT device  MUST, by default, generate "Time Exceeded" ICMP
   error message when it discards a packet due to an expired TTL field,
   unless explicitly configured otherwise.

cheers,
suresh