NAT Behavioral Requirements for ICMP
draft-ietf-behave-nat-icmp-12

Hi Suresh,

I sent you a separate test ping message yesterday but I suspect you did not get that and I'm worried you are not getting any email from me - glad to do anything to help debug this and can add another email address to the tracker if you want so you get notifications to two places. Dan or Magnus, can you forward a copy of this to Suresh just in case ....

More inline ...



The TTL behavior in section 7.2 has the text

NAT implementers are reminded that the requirements
in Section
5.2.7.3 of [RFC1812] apply to NATs, as well.

As I don't see where is NATs are required to do
this, I think
this needs to be removed and replaced with text on how
to
handle TTL or leave that to the actual transport
protocol
documents. (I note both the UDP and TCP draft are
lacking on
this). If advice is added here, I'd be looking for
the usual
policy can disable sending as with other ICMP packets,
advice
on if the TTL is decremented by 1 or 2 or either is
fine when
a packet traverses the NAT, and what happens when the
TTL hits zero.

[suresh] The document has several places where it mentions that NATs need to support the popular application tracert.
Yep, agree that is one of the key goals of this doc.

This can be found in the sections preceding Req-1 and Req-2. In order to support tracert (ICMP or UDP based), NATs MUST generate "Time Exceeded" ICMP Error message when it discards a packet due to an expired TTL field. If you like, I could add text to that effect here.

Hmm - I can't find where it talks about this other than section 7.2



Would the above fix clear your DISCUSS? Thanks.
Sounds good - I'm fine with section 7.2 being replaced with some text that says something along lines of "MUST generate "Time Exceeded" ICMP Error message when it discards a packet due to an expired TTL field" -  it would need the usual, "unless policy prohibits" for stuff from outside

I think everyone agrees on what NATs need to do here - we just need to get that into the spec





Comment:
This draft has changed substantially since the version
that
went to WGLC and IETF LC. I feel very uncomfortable
with
having all these changes only looked at by 4 people.

[Suresh] Cullen -  All discussion to resolve your discuss comment did take place on the WG list. Dan did request the WG to review the document and send comments.  And, we did receiv comments on the list. Dan summarized the comments and posted to the list, which I promptly folded into the document. Even Magnus's comments were posted on the list, before being folded into the document.

Fair enough - I have lost track of what portion of this was reviewed on list and what was not - this is only a comment - as long as Dan and Magnus are happy, then I have no problem with that. I just wanted to flag it for them and I'm fine with whatever they decide on this. Sounds like there were already well aware of this and had a plan before I even raised it. I understand this document has had more than it's fair share of WGLC already.

[Ballot comment]
This draft has changed substantially since the version that went to WGLC and IETF LC. I feel very uncomfortable with having all these changes only looked at by 4 people. It's up to Dan and Magnus, but I think a short WGLC might catch a mistake or two and confirm we actually had WG consensus for these changes.

[Ballot discuss]
The latest draft is looking very good and I think we are close to done. I do have a problem claiming a NAT is a router in the 1812 sense or the word and I think we have all of that fixed except in two remaining place.

Where the draft says

  NAT devices should follow the best current practices of modern
  routers when handling ICMP messages, as specified in Section 4.3 of
  [RFC1812].

The rest of the draft is not consistent with that now. I think this should be reworded to something more like

  This document specifies NATs to have a behavior which is consistent
  with the way routers handle ICMP messages, as specified in Section 4.3 of
  [RFC1812].

The TTL behavior in section 7.2 has the text

  NAT implementers are reminded that the requirements in Section
  5.2.7.3 of [RFC1812] apply to NATs, as well.

As I don't see where is NATs are required to do this, I think this needs to be removed and replaced with text on how to handle TTL or leave that to the actual transport  protocol documents. (I note both the UDP and TCP draft are lacking on this). If advice is added here, I'd be looking for the usual policy can disable sending as with other ICMP packets, advice on if the TTL is decremented by 1 or 2 or either is fine when a packet traverses the NAT, and what happens when the TTL hits zero.

Finally managed to get Cullen into a phone conference to resolve this. The main issue is that we still point to requirement that aren't desirable to force on NAT implementors like source route. Even if it is possible to read out of the documents which messages is to be supported this can be greatly improved. Draft text will be passsed to the authors and then presented to the WG before going forward.

[Ballot discuss]
The document requires implementation of some parts of RFC 1812 section 4.3 which I don't think there was WG consensus (or even discussion) to include. For example, source route. The WG chair has kindly agreed to work through sorting out a proposal of what parts of 1812 section 4.3 is needed.

[Ballot discuss]
I have a bunch of issues here but they are all very easy to resolve.

The document states a NAT is a router and MUST conform to all requirements in 1812. As I pointed out in my email to the WG list on March 16, I don't think a NAT can or should meet all the requirements of 1812, for example "A router MUST NOT reassemble any datagram before forwarding it."  It is difficult for a NAT to figure out where to forward the fragments without reassembling so many do. More importantly, the point of BEHAVE was to produce a simple set of requirements that NAT vendors can easily use to produce NATs that have predictable behavior such that we can design protocols that reliably work with them. Saying you must do everything in 1812 is not going to help with the that goal. I doubt that many people in the WG read all of 1812 to decide if this was a reasonable requirement or not. I'm pretty confident that most the SOHO NAT software engineers will not. If there are specific things needed from 1812 that some non trivial percentage of NAT vendors are not doing and these are things that we need to be able to build applications that use NATs, then I think we should specifically call out theses items in this document so that implementers know they need to do them. I don't think a NAT should meet all the requirements in 1812 - this could be resolved simply by removing this.

The document states that a NAT is a host and should be bound by all the requirements in RFC 1122 other than specific exceptions that aren't explicitly provided. I don't think this is possible or a good idea. RFC 1122 requires.  "When a host sends any datagram, the IP source address MUST  be one of its own IP addresses ...".  There are case where a NAT can't  do this on a packet going from the outside to the inside. This and some of the other issues could be resolved by removing section 7.

There are several places where normative language is added outside of the actual numbered requirements, often in a way that duplicates what is said in the numbered requirements. This leads to situation like the first MUST in the document which is contradicts Req-1 by not being policy scoped. This type of contradicting information in the document will cause different interpretations of the document. This could be resolved by removing all the normative language that is outside one of the numbered requirements.  This will also mean that summary of the requirements actually does capture all the normative requirements and can be simply used for NAT specifications. The high level point is we have to make sure that the number requirements don't contradict the rest of the document - if folks want to fix this by leaving it roughly as is and fixing the contradictions I can provide more specifics.

Section 4 defines how the NAT deal with ICMP packets generated from errors in other transport protocols. The WG explicitly agreed to put that in the documents for each transport protocol and not in this document. Having them in two places will lead to contradictions and confusion. Since they are already defined in other RFC for the specific transports, I believe it will be harmful to duplicate them in this document if they are subtly different in their definition here. This could be simply resolved by removing the appropriate sections.


The document provides no guidance on what to do with any ICMP message published in an RFC after 1122. I note that 1122 was published in October 1989. This is really concerning and was added into very late in the WG process with close to no comments for discussion. I think that ignoring this is harmful for all the ICMP stuff defined since then and would prefer to see the draft deal with current and future ICMP messages or at least have some explanation of why this was not possible. I suspect that this could be resolved by simply removing the post 1122 language and then resolving some of the other issues raised here will make the problem go away.

The some of the usage of "NAT Session" in this document is inconsistent with the definition of it from 4008 where it is defined only for UDP and TCP. The could easily be resolve d by simply defining the term in this document and removing the reference to 4008.

[Ballot discuss]
I have a bunch of issues here but they are all very easy to resolve.

The document states a NAT is a router and MUST conform to all requirements in 1812. As I pointed out in my email to the WG list on March 16, I don't think a NAT can or should meet all the requirements of 1812, for example "A router MUST NOT reassemble any datagram before forwarding it."  It is difficult for a NAT to figure out where to forward the fragments without reassembling so many do. More importantly, the point of BEHAVE was to produce a simple set of requirements that NAT vendors can easily use to produce NATs that have predictable behavior such that we can design protocols that reliably work with them. Saying you must do everything in 1812 is not going to help with the that goal. I doubt that many people in the WG read all of 1812 to decide if this was a reasonable requirement or not. I'm pretty confident that most the SOHO NAT software engineers will not. If there are specific things needed from 1812 that some non trivial percentage of NAT vendors are not doing and these are things that we need to be able to build applications that use NATs, then I think we should specifically call out theses items in this document so that implementers know they need to do them. I don't think a NAT should meet all the requirements in 1812 - this could be resolved simply by removing this.

The document states that a NAT is a host and should be bound by all the requirements in RFC 1122 other than specific exceptions that aren't explicitly provided. I don't think this is possible or a good idea. RFC 1122 requires.  "When a host sends any datagram, the IP source address MUST  be one of its own IP addresses ...".  There are case where a NAT can't  do this on a packet going from the outside to the inside. This and some of the other issues could be resolved by removing section 7.

There are several places where normative language is added outside of the actual numbered requirements, often in a way that duplicates what is said in the numbered requirements. This leads to situation like the first MUST in the document which is contradicts Req-1 by not being policy scoped. This type of contradicting information in the document will cause different interpretations of the document. This could be resolved by removing all the normative language that is outside one of the numbered requirements.  This will also mean that summary of the requirements actually does capture all the normative requirements and can be simply used for NAT specifications.

Section 4 defines how the NAT deal with ICMP packets generated from errors in other transport protocols. The WG explicitly agreed to put that in the documents for each transport protocol and not in this document. Having them in two places will lead to contradictions and confusion. Since they are already defined in other RFC for the specific transports, I believe it will be harmful to duplicate them in this document if they are subtly different in their definition here. This could be simply resolved by removing the appropriate sections.


The document provides no guidance on what to do with any ICMP message published in an RFC after 1122. I note that 1122 was published in October 1989. This is really concerning and was added into very late in the WG process with close to no comments for discussion. I think that ignoring this is harmful for all the ICMP stuff defined since then and would prefer to see the draft deal with current and future ICMP messages or at least have some explanation of why this was not possible. I suspect that this could be resolved by simply removing the post 1122 language and then resolving some of the other issues raised here will make the problem go away.

The some of the usage of "NAT Session" in this document is inconsistent with the definition of it from 4008 where it is defined only for UDP and TCP. The could easily be resolve d by simply defining the term in this document and removing the reference to 4008.

[Ballot discuss]
I have a bunch of issues here but they are all very easy to resolve.

The document states a NAT is a router and MUST conform to all requirements in 1812. As I pointed out in my email to the WG list on March 16, I don't think a NAT can or should meet all the requirements of 1812, for example "A router MUST NOT reassemble any datagram before forwarding it."  It is difficult for a NAT to figure out where to forward the fragments without reassembling so many do. More importantly, the point of BEHAVE was to produce a simple set of requirements that NAT vendors can easily use to produce NATs that have predictable behavior such that we can design protocols that reliably work with them. Saying you must do everything in 1812 is not going to help with the that goal. I doubt that many people in the WG read all of 1812 to decide if this was a reasonable requirement or not. I'm pretty confident that most the SOHO NAT software engineers will not. If there are specific things needed from 1812 that some non trivial percentage of NAT vendors are not doing and these are things that we need to be able to build applications that use NATs, then I think we should specifically call out theses items in this document so that implementers know they need to do them. I don't think a NAT should meet all the requirements in 1812 - this could be resolved simply by removing this.

The document states that a NAT is a host and should be bound by all the requirements in RFC 1122 other than specific exceptions that aren't explicitly provided. I don't think this is possible or a good idea. RFC 1122 requires.  "When a host sends any datagram, the IP source address MUST  be one of its own IP addresses ...".  There are case where a NAT can't  do this on a packet going from the outside to the inside. This and some of the other issues could be resolved by removing section 7.

There are several places where normative language is added outside of the actual numbered requirements, often in a way that duplicates what is said in the numbered requirements. This leads to situation like the first MUST in the document which is contradicts Req-1 by not being policy scoped. This type of contradicting information in the document will cause different interpretations of the document. This could be resolved by removing all the normative language that is outside one of the numbered requirements.  This will also mean that summary of the requirements actually does capture all the normative requirements and can be simply used for NAT specifications.

Section 4 defines how the NAT deal with ICMP packets generated from errors in other transport protocols. The WG explicitly agreed to put that in the documents for each transport protocol and not in this document. Having them in two places will lead to contradictions and confusion. Since they are already defined in other RFC for the specific transports, I believe it will be harmful to duplicate them in this document especially as they are subtly different in their definition here. This could be simply resolved by removing the appropriate sections.

The security section issues on NAT defending hosts inside the NAT that are not able to defend themselves is  a firewall issues and are out of scope for BEHAVE.

The document provides no guidance on what to do with any ICMP message published in an RFC after 1122. I note that 1122 was published in October 1989. This is really concerning and was added into very late in the WG process with close to no comments for discussion. I think that ignoring this is harmful for all the ICMP stuff defined since then and would prefer to see the draft deal with current and future ICMP messages or at least have some explanation of why this was not possible. I suspect that this could be resolved by simply removing the post 1122 language and then resolving some of the other issues raised here will make the problem go away.

The some of the usage of "NAT Session" in this document is inconsistent with the definition of it from 4008 where it is defined only for UDP and TCP. The could easily be resolve d by simply defining the term in this document and removing the reference to 4008.

I note most of these were pointed out on the behave list before WGLC and the WG did not seem to disagree with them.

[Ballot discuss]
This document is much needed, thanks for writing it!

I agree though with the Discusses and Comments given by other ADs. In addition, I would raise the following issues and suggestions:

3. I would suggest that the ICMP related requirements from router/host requirements documents be brought forward and explicitly listed, rather than blindly requiring the NAT to support everything. This is a suggestion related to Cullen Jennings' Discuss.

4. I would suggest that Chris Newman's policy reformulation Comment be addressed. (And I'm making this a Discuss-level requirement.)

5. The needed changes in the document are big enough that I would like to see the document revised and brought back to the IESG for a clean new review (and possibly a second IETF Last Call).

[Ballot discuss]
This document is much needed, thanks for writing it!

I agree though with the Discusses and Comments given by other ADs. In addition, I would raise the following issues and suggestions:

1. It seems more logical for the NAT to preserve an incorrect inner checksum (or recreate it correctly) than to drop the packet. This is a suggestion related to Lars Eggert's Discuss.

2. Given that ICMP extensions now exist, it might make sense to require supporting the extended format in NATs. IMHO this is simpler than explaining the corner cases and having to deal with them. This is an upgrade of Ron Bonica's Comment to a Discuss.

3. I would suggest that the ICMP related requirements from router/host requirements documents be brought forward and explicitly listed, rather than blindly requiring the NAT to support everything. This is a suggestion related to Cullen Jennings' Discuss.

4. I would suggest that Chris Newman's policy reformulation Comment be addressed. (And I'm making this a Discuss-level requirement.)

5. The needed changes in the document are big enough that I would like to see the document revised and brought back to the IESG for a clean new review (and possibly a second IETF Last Call).

[Ballot comment]
REQ-9 in summary has a different (and incorrect) capitalization
of the Packet Too Big message from what appeared in the body
of the document.

[Ballot discuss]
I have a bunch of issues here but they are all very easy to resolve.

The document states a NAT is a router and MUST conform to all requirements in 1812. As I pointed out in my email to the WG list on March 16, I don't think a NAT can or should meet all the requirements of 1812, for example "A router MUST NOT reassemble any datagram before forwarding it."  It is difficult for a NAT to figure out where to forward the fragments without reassembling so many do. More importantly, the point of BEHAVE was to produce a simple set of requirements that NAT vendors can easily use to produce NATs that have predictable behavior such that we can design protocols that reliably work with them. Saying you must do everything in 1812 is not going to help with the that goal. I doubt that many people in the WG read all of 1812 to decide if this was a reasonable requirement or not. I'm pretty confident that most the SOHO NAT software engineers will not. If there are specific things needed from 1812 that some non trivial percentage of NAT vendors are not doing and these are things that we need to be able to build applications that use NATs, then I think we should specifically call out theses items in this document so that implementers know they need to do them. I don't think a NAT should meet all the requirements in 1812 - this could be resolved simply by removing this.

The document states that a NAT is a host and should be bound by all the requirements in RFC 1122 other than specific exceptions that aren't explicitly provided. I don't think this is possible or a good idea. RFC 1122 requires.  "When a host sends any datagram, the IP source address MUST  be one of its own IP addresses ...".  There are case where a NAT can't  do this on a packet going from the outside to the inside. This and some of the other issues could be resolved by removing section 7.

Given the issues around 4884, having the NAT drop a packet in the IP checksum of the embedded packets fail to validate seems like it will break things that would otherwise work and is thus will harm interoperability. I would like to either clearly understand why this is the best path or remove it.


There are several places where normative language is added outside of the actual numbered requirements, often in a way that duplicates what is said in the numbered requirements. This leads to situation like the first MUST in the document which is contradicts Req-1 by not being policy scoped. This type of contradicting information in the document will cause different interpretations of the document. This could be resolved by removing all the normative language that is outside one of the numbered requirements.  This will also mean that summary of the requirements actually does capture all the normative requirements and can be simply used for NAT specifications.

Section 4 defines how the NAT deal with ICMP packets generated from errors in other transport protocols. The WG explicitly agreed to put that in the documents for each transport protocol and not in this document. Having them in two places will lead to contradictions and confusion. Since they are already defined in other RFC for the specific transports, I believe it will be harmful to duplicate them in this document especially as they are subtly different in their definition here. This could be simply resolved by removing the appropriate sections.

The security section issues on NAT defending hosts inside the NAT that are not able to defend themselves is  a firewall issues and are out of scope for BEHAVE.

The document provides no guidance on what to do with any ICMP message published in an RFC after 1122. I note that 1122 was published in October 1989. This is really concerning and was added into very late in the WG process with close to no comments for discussion. I think that ignoring this is harmful for all the ICMP stuff defined since then and would prefer to see the draft deal with current and future ICMP messages or at least have some explanation of why this was not possible. I suspect that this could be resolved by simply removing the post 1122 language and then resolving some of the other issues raised here will make the problem go away.

The some of the usage of "NAT Session" in this document is inconsistent with the definition of it from 4008 where it is defined only for UDP and TCP. The could easily be resolve d by simply defining the term in this document and removing the reference to 4008.

I note most of these were pointed out on the behave list before WGLC and the WG did not seem to disagree with them.

[Ballot comment]
In section 3.2, first sentence.
  When an application initiates an ICMP Query that transits a NAT
  device, the NAT associates a timer to the ICMP Query NAT session.
Using a timer is one way to implement this but not the only way, for example some NATs use a hash approach and never invalidate until there is a hash collision. I think it would be better to write this in a way that does not assume or describe a specific implementation and instead just puts a requirement on the time.


The WG has removed the milestone to produce BEH-APP referenced in " A
  separate document [BEH-APP] provides recommendations for application
  designers on how to make applications work robustly over NATs that
  follow the requirements specified here and the adjunct
  protocol-specific BEHAVE documents."
It seems that ICE would be a better reference here.

The document has
"a NAT device MUST transparently forward any"
I don't think that the forward is done transparently - it may be that we don't have the same definition of transparent in this context. I might suggest just removing the word transparently.

I have no idea how one comes to the 10 second conclusion for all environments
  In practice, ICMP Ping ([RFC1470]) and ICMP traceroute ([MS-TRCRT]),
  the two most commonly known legacy applications built on top of ICMP
  Query messages take less than 10 seconds to complete a round trip,
  when the target node is operational on the network.
If this is true, we should go change MSL in the transport protocols.

"Query id" is used inconstantly in the document. Some times it is "Query Id", some times it is "Query identifier".

[Ballot comment]
COMMENT:

In Section 4.1, you say that if an ICMP Error message includes the entire embedded packet, the NAT box should try to validate its checksum. If the checksum doesn't validate, the NAT box should discard the ICMP Error message.

There is one corner case in which this rule, in conjuncton with ICMP-EXT will cause the NAT box to erroneously discard an ICMP message. That's not so bad, and even if the NAT box were to pass the ICMP message, the receiving host would likely discard it. This corner case is documented in RFC 4884. You should probably mention the corner case in this document, too.

In the corner case, the ICMP error message is not compliant with RFC 4884. It fails to set the length attribute for the embedded packet. It includes exactly 128 octets of the original packet and then appends the ICMP extensions to that. (Many legacy implementations behave this way.)

Let's assume that the original packet contained 128 + X octet and the extension structure contained exactly X octets. The NAT box would erroneously interpret the extension structure as being the final X bytes of the packet and would calculate the checksum incorrectly. Therefore, the NAT box would discard the packet.

DISCUSS:

  ** In Section 3.1 you say:

The mapping of ICMP Query identifier within the NAT device SHOULD
  be external endpoint independent. Say, an internal host A sent an
  ICMP Query out to an external host B using Query Id X. And, say,
  the NAT assigned this an external mapping of Query id X' on the
  NAT's public address. If host A reused the Query Id X to send ICMP
  Queries to the same or different external host, the NAT device
  SHOULD reuse the same Query Id mapping (i.e.,  map private host's
  Query id X to Query id X' on NAT's public IP address) instead of
  assigning a different mapping.

How long should the NAT hold X' reserved for this use? Until it sees a response for the initial query? Forever?

Also concur with Lars' DISCUSS

[Ballot comment]
I suspect the last occurrence of the word "Error" should be removed in
the following text:

  do not have an "Identifier" field within the messages. Likewise,
  there are other ICMP messages defined in [RFC4065] that do not
  fall in either of ICMP Query or ICMP Error message categories, but
  will be referred as Post-1122 ICMP Error messages.
                                      ^^^^^

I'm not a big fan of the "When local policy permits" language because a
NAT vendor could simply say "our default local policy is to block ICMP"
and be compliant with the letter of the text.  I'd prefer a phrasing
like "Unless local policy explicitly overrides," or "SHOULD/MUST do X
when operating with the default configuration, MAY allow X to be
disabled as a matter of explicit local policy".

This statement makes an implementation assumption about a NAT:
  When an application initiates an ICMP Query that transits a NAT
  device, the NAT associates a timer to the ICMP Query NAT session.
  This is so the ICMP Query NAT session is freed up if the NAT session
  remains idle for longer than the timeout set by the timer.
Timers are only one implementation technique to keep resource consumption
finite.  There are other techniques.  The document quality would be
improved if it didn't make implementation assumptions.

I also concur with Lars' DISCUSS.

[Ballot comment]
I suspect the last occurrence of the word "Error" should be removed in
the following text:

  do not have an "Identifier" field within the messages. Likewise,
  there are other ICMP messages defined in [RFC4065] that do not
  fall in either of ICMP Query or ICMP Error message categories, but
  will be referred as Post-1122 ICMP Error messages.
                                      ^^^^^

I'm not a big fan of the "When local policy permits" language because a
NAT vendor could simply say "our default local policy is to block ICMP"
and be compliant with the letter of the text.  I'd prefer a phrasing
like "Unless local policy explicitly overrides," or "SHOULD/MUST do X
when operating with the default configuration, MAY allow X to be
disabled as a matter of explicit local policy".

This statement makes an implementation assumption about a NAT:
  When an application initiates an ICMP Query that transits a NAT
  device, the NAT associates a timer to the ICMP Query NAT session.
  This is so the ICMP Query NAT session is freed up if the NAT session
  remains idle for longer than the timeout set by the timer.
Timers are only one implementation technique to keep resource consumption
finite.  There are other techniques.  The document quality would be
improved if it didn't make implementation assumptions.

I also concur with Lars' DISCUSS.

[Ballot comment]
I suspect the last occurrence of the word "Error" should be removed in
the following text:

  do not have an "Identifier" field within the messages. Likewise,
  there are other ICMP messages defined in [RFC4065] that do not
  fall in either of ICMP Query or ICMP Error message categories, but
  will be referred as Post-1122 ICMP Error messages.
                                      ^^^^^

I'm not a big fan of the "When local policy permits" language because a
NAT vendor could simply say "our default local policy is to block ICMP"
and be compliant with the letter of the text.  I'd prefer a phrasing
like "Unless local policy explicitly overrides," or "SHOULD/MUST do X
when operating with the default configuration, MAY allow X to be
disabled as a matter of explicit local policy".

This statement makes an implementation assumption about a NAT:
  When an application initiates an ICMP Query that transits a NAT
  device, the NAT associates a timer to the ICMP Query NAT session.
  This is so the ICMP Query NAT session is freed up if the NAT session
  remains idle for longer than the timeout set by the timer.
Timers are only one implementation technique to keep resource consumption
finite.  There are other techniques.  The document quality would be
improved if it didn't make implementation assumptions.

I also concur with Lars' DISCUSS.

[Ballot comment]
You say:

The mapping of ICMP Query identifier within the NAT device SHOULD
  be external endpoint independent. Say, an internal host A sent an
  ICMP Query out to an external host B using Query Id X. And, say,
  the NAT assigned this an external mapping of Query id X' on the
  NAT's public address. If host A reused the Query Id X to send ICMP
  Queries to the same or different external host, the NAT device
  SHOULD reuse the same Query Id mapping (i.e.,  map private host's
  Query id X to Query id X' on NAT's public IP address) instead of
  assigning a different mapping. This is similar to the "endpoint
  independent mapping" requirement specified in the

How long should the NAT hold X' reserved for this use? Until it sees a response for the initial query? Forever?

Also concur with Lars' DISCUSS

[Ballot comment]
You say:

The mapping of ICMP Query identifier within the NAT device SHOULD
  be external endpoint independent. Say, an internal host A sent an
  ICMP Query out to an external host B using Query Id X. And, say,
  the NAT assigned this an external mapping of Query id X' on the
  NAT's public address. If host A reused the Query Id X to send ICMP
  Queries to the same or different external host, the NAT device
  SHOULD reuse the same Query Id mapping (i.e.,  map private host's
  Query id X to Query id X' on NAT's public IP address) instead of
  assigning a different mapping. This is similar to the "endpoint
  independent mapping" requirement specified in the

How long should the NAT hold X' reserved for this use? Until it sees a response for the initial query? Forever?

[Ballot comment]
The issue of 4.1 appears to be under active discussion w/ Carlos, Lars, Suresh and they are working towards resolution. I put this comment here to note that the outcome of their discussion must be reflected in a new version of the draft if changes are necessary.

[Ballot discuss]
In section 4.1, paragraph two the document states

                                                                              In the case the ICMP
  Error payload includes ICMP extensions ([ICMP-EXT]), the NAT device
  SHOULD exclude the optional zero-padding and the ICMP extensions
  when evaluating transport checksum for the embedded packet. If the
  transport checksum fails, the NAT device SHOULD drop the Error
  packet.

Why isn't the first SHOULD a MUST?  If the optional zero-padding and
the ICMP extensions were excluded when transport checksum was
calculated, but the NAT device doesn't excclude them, the check will fails
right?  Then the second SHOULD tells the NAT device to drop the packet.

What am I missing?  I tried to chase this down in [ICMP-EXT], but failed.

[Ballot comment]
I'd like to strongly agree with Lars's discuss on section 4.1.  A NAT
is not a security firewall.  NATs may be combined with security
firewalls, but doing so is out of scope for behave as I understand it.
The NAT functionality does not benefit from a NAT validating ICMP
errors.

It may be the case that security functionality in a NAT+firewall does
this validation.  However that's outside of the scope of this
document.

[Ballot comment]
Section 240, paragraph 0:
>    ICMP Query session timer MUST not expire in less than 60 seconds. We

  s/MUST not/MUST NOT/

Section 240, paragraph 1:
>    RECOMMEND however that the administrator(s) be allowed to configure

  RECOMMEND is not an RFC2119 term. You need to rephrase to say
  RECOMMENDED, MUST or REQUIRED. (Or use lowercase here, because REQ-2
  has the correct 2119 phrasing.)

[Ballot discuss]
Section 4.1., paragraph 4:
>    REQ-3:  When an ICMP Error packet is received, the NAT device
>    SHOULD do the following.
>    a) If the IP checksum of the embedded packet fails to validate, drop
>    the Error packet

  DISCUSS: I disagree. (And I apologize for not catching this during my
  earlier review.) The reason that (part of) the packet that caused an
  ICMP message to be generated is included is for diagnostic purposes,
  so the end hosts can determine what went wrong and determine whether
  they need to react in some way. This can't happen if NATs drop these
  packets. Also, the reason why some end system OSs drop ICMP messages
  with invalid checksums is to protect against some attacks. NATs,
  however, are not firewalls. It is inappropriate for this document to
  specify NAT mechanisms that implement a specific security policy.
  There is also no IETF standard that recommends that end hosts drop
  ICMP packets with payloads that have invalid checksums, which is
  another reason why this document should not recommend that NATs do
  this. (And, as an aside, the effectiveness of this "security" measure
  is questionable, because if I can't spoof the complete packet with a
  valid checksum, I'd just include a partial packet in the payload, for
  which you can't validate the checksum, but that you must still act
  on.)

PROTO Write-up

(1.a) Who is the Document Shepherd for this document?

Dan Wing, dwing@cisco.com


Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Yes.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

This document has been reviewed extensively within BEHAVE, TCPM (Joe
Touch), and authors of draft-ietf-tcpm-icmp-attacks and
RFC4963.



(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

No.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

ICMP payload validation (section 4.1 in the document) encourages NATs
to validate ICMP packets. The document shepherd is concerned this may
cause difficulties with ICMP extensions that the NAT is unaware of.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

It represents a relatively solid WG consensus.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No such concerns have been raised.



(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

All nits are satisfied.

Document is intended to be BCP.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

All references have been double-checked and appear accurate.


(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

There are no IANA considerations for this document.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Document contains no formal language.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.


This document specifies the behavioral properties required of the
Network Address Translator (NAT) devices in conjunction with the
ICMP protocol. The objective of this memo is to make NAT devices
more predictable and compatible with diverse application protocols
that traverse the devices. Companion documents provide behavioral
recommendations specific to TCP, UDP and other protocols.


Working Group Summary
Was there anything in the WG process that is worth noting?
For example, was there controversy about particular points
or were there decisions where the consensus was
particularly rough?

No significant controversy.


Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification?

This is a BCP document, and describes current practice in existing NATs,
and describes some improvements to current practice.


Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?

They have been acknowledged in the acknowledgements section.

If
there was a MIB Doctor, Media Type, or other Expert Review,
what was its course (briefly)? In the case of a Media Type
Review, on what date was the request posted?

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are .'

Document shepherd: Dan Wing, dwing@cisco.com
Responsible AD: Magnus Westerlund, magnus.westerlund@ericsson.com