An Acceptable Use Policy for New ICMP Types and Codes
draft-shore-icmp-aup-12

[Ballot discuss]
I DISCUSSed this with Benoit and he has asked me to continue to hold this DISCUSS until he has a chance to talk with the authors and shepherd to determine if this document has sufficient consensus to go forward. I await his reply.

The shepherd writeup says, "This document is not the product of any WG. It is AD sponsored. However, it has been reviewed by the OPSAREA and INTAREA WGs"

I went looking through the archives (Googling) and found this message (and its thread):

http://www.ietf.org/mail-archive/web/ipv6/current/msg19850.html

That had two reviews, one of which said, "I don't understand the motivation of the document" and the other of which said, "I'm not an expert on this stuff, but here are some comments." I couldn't find any other significant reviews, and importantly I couldn't find any messages that indicated this was important work that needed to be published as a BCP. Can someone give me some pointers to where this was actually discussed, and some indication that there is some consensus in the community that the AUP documented here is a good and necessary thing? It's fine if it's only a few experts (of which I am not one) think it's important to say this stuff and everyone else just shrugs and says, "Whatever". But I'd like to see some indication of that. I hope I'm just a bad googler, but I'm not clear there is consensus for this.

[Ballot comment]
The latest version cleans things up even further. Thanks!

I am now reduced to a few minor Comments that I will leave for the authors and responsible AD to debate. No need to come back to me unless you want to.

===

Continuing with Section 2.1.1. You have

  From a more pragmatic
  perspective, some of the key characteristics of ICMP do not support
  using it as a routing protocol.  Those include...

I wonder whether the issue is the word "support" or the generality of the statement you make about "a routing protocol". It is clear to me that, not withstanding all of the characteristics of ICMP, RPL is a routing protocol.

I would suggest either:
s/do not support using it as/make it a less than ideal choice for/
or
s/as a routing protocol/as a routing protocol in the Internet/

(or both)

---

And continuing the conversation about 2.1.2. You have
 
  RPL...
  ... the expansion of its acronym appears
  to be an actual general routing protocol.

This "appears" is really annoying me. We, in the IETF, have access to the RFCs and can look them up. RPL *is* a routing protocol.

I suggest replacing the whole paragraph as...

  RPL, the IPv6 Routing protocol for low-power and lossy networks (see
  [RFC6550]) uses ICMP as a transport.  In this regard it is an exception among the
  ICMP message types.  Note that, although RPL is an IP routing protocol, it is not
  deployed on the general Internet, but is limited to specific, contained networks.

[Ballot comment]
Thank you for the work to address my Discuss. The latest revision is much improved and leaves me with just some Comments. I hope you will find it in your heart to address them :-)

===

The new Section 2.1.1 is interesting. It is good that you have listed some of the reasons why you consider that ICMP is not suitable for use "as a general-purpose routing or network management protocol."

- Did you mean "as a transport for" or what you wrote.

- I guess "general-purpose" lets a lot of fish off a lot of hooks, and
  in that regard, this document would certainly not oppose RPL if it
  was being started today

- The example reasons you cite are fine, but would not be issues
  in the specialist networks where RPL is found

- I wonder whether an important factor that you have not cited is
  the specialist hardware processing of ICMP that would disrupt the
  deployment of an ICMP-based routing or management protocol.
  Perhaps this is what "frequently filtered" means, although I took
  that to apply to domain boundaries where, of course, routing
  is not happening.

---

Section 2.1.2 is much improved, thanks.

- I still don't understand the use of "appears" in
    It is something of an outlier
    among the existing ICMP message types, as the expansion of its
    acronym appears to be an actual routing protocol
  Whatever the expansion of its acronym appears, it *is* a routing protocol.
Maybe also, "something of an outlier" would be better as "an exception".

- I think that a lot of hand-waving is going on behind the term "discovery
  protocol". Are you able to constrain what is discovered about which things
  and by whom? If you aren't then I foresee that many people will come back
  and say "but I am only using it to discover the colours of the LEDs on the
  power supply in my POP" or "but I am only discovering the best path across
  the Internet".

---

The new Section 2.2 seems valid, but I hope you understand the box you have opened. You are saying that anything I do that uses existing message types is OK even if it causes the network to thrash :-) Maybe more importantly, you appear to have said that so long as I piggyback my new management protocol on top of existing ICMP messages, everything is OK.

Maybe...
OLD
  These
  uses are considered acceptable as they do not add new message types
  to ICMP.
NEW
  These
  uses are considered acceptable as they use existing ICMP message types
  and do not change ICMP functionality.
END
 
---

Section 4 is gone. Hoorah!
You need to delete the last sentence of Section 3.

[Ballot discuss]
I still haven't heard a response to my question, so I'm going to make this a DISCUSS. The shepherd writeup says, "This document is not the product of any WG. It is AD sponsored. However, it has been reviewed by the OPSAREA and INTAREA WGs"

I went looking through the archives (Googling) and found this message (and its thread):

http://www.ietf.org/mail-archive/web/ipv6/current/msg19850.html

That had two reviews, one of which said, "I don't understand the motivation of the document" and the other of which said, "I'm not an expert on this stuff, but here are some comments." I couldn't find any other significant reviews, and importantly I couldn't find any messages that indicated this was important work that needed to be published as a BCP. Can someone give me some pointers to where this was actually discussed, and some indication that there is some consensus in the community that the AUP documented here is a good and necessary thing? It's fine if it's only a few experts (of which I am not one) think it's important to say this stuff and everyone else just shrugs and says, "Whatever". But I'd like to see some indication of that. I hope I'm just a bad googler, but I'm not clear there is consensus for this.

[Ballot discuss]
I support the Discusses of Adrian and Brian, and would particularly
like to discuss the following with the authors.

  "It is typically the case that routing protocols have transport
  requirements that are not met by ICMP.  For example, there will be
  reliability guarantees and security guarantees that are not provided
  by ICMP, forcing protocol developers to design their own mechanisms.
  Given the availability of other IETF standard transports for routing,
  this reinvention should be avoided."

This is somewhat belittling of the routing protocol designers, who have
existence proof that they understand the finer points of their art. It should
be removed.

"3.  ICMP's role in the internet"

Surely ICMP is first and foremost the IP layer OAM?

Similarly Section 4 is seeming confused because it does not consider
ICMP as an OAM protocol.

Section 3 and 4 could and should be simplified by focusing on the
role of ICMP rather than its name which pre-dates the IETF's more
developed understanding of OAM protocols.

[Ballot comment]
I have no objection to publishing this draft, but the current discussions taking place during IESG Evaluation seem to identify changes that would be very helpful if the document reflected at least some of them.

[Ballot comment]
Was odd to see photuris dredged up here. Since it lost out to isakmp / IKE around 1996 I'm not sure that  it's illustrative of much with respect to ICMP except as a side channel into the inner-workings of the ipsec working-group.

I find on revisiting this that I'm somewhat unsatisfied with the ontology described in section 4 (something it admits to). the premise of and AUP hinges in fact no there being appropriate or inappropriate actions.

I doubt this is really discuss-worthy however.

[Ballot comment]

- I'm not sure that AUP is a good term here really

- I guess discussion of Brian's discuss might sort out
this comment but I didn't find the acceptable uses
described at the top of section 2 clear.

- Would it be worth adding something to the security
considerations that e.g. new ICMP stuff needs to
consider how ICMP can be abused (e.g. [1])?

  [1] https://www.nordu.net/articles/smurf.html

[Ballot comment]
Was odd to see photuris dredged up here. Since it lost out to isakmp / IKE around 1996 I'm not sure that  it's illustrative of much with respect to ICMP except as a side channel into the inner-workings of the ipsec working-group.

[Ballot discuss]
I am going to start this as a DISCUSSion and we will see where it goes from there...

First of all, I agree with a large majority of Adrian's DISCUSS points.

I am having a really hard time seeing what this document will accomplish.  If it had been written 20 years ago, I think it would have had a significant impact on the development of many protocols and probably would have improved some of them.  That being said, I don't see the benefit now.

In ICMPv4, not counting the two Types defined for Experimentation, the last Type was registered 8.5 years ago.  Are we expecting a rash of ICMPv4 messages to be defined in the near future?

One could argue that ICMPv6 is a different story.  However, the base spec for ICMPv6 (RFC 4443) clearly states that ICMPv6 is going to be used as an integral part of the IPv6 protocol suite.  It supports link-local functions like neighbor discovery and multicast group management.  It also supports Internet-wide functions like Path MTU Discovery and mobility management in addition to the general purpose error/informational messaging.  In other words, the core IPv6 architecture assumes ICMPv6 will be an integral part of the protocol suite.  That also means that the statement in section 2.3 about why firewalls and routers have more control over ICMPv6 messages is rather incomplete.

Given the above, is the intent of this AUP to preclude the extension of ICMPv6?  Will an update to an existing (e.g., mobility) protocol that currently use ICMPv6 be required to migrate to a different approach?  I am not sure that the two broad categories in section 2 are clear enough with respect to how the IPv6 architecture envisions the use of ICMPv6.

[Ballot comment]
I have absolutely no objection to this document.  The only comment I have is that (modulo Pete's comment) I think it should be Standards Track (an Applicability Statement), and not BCP.  It's not worth arguing about it and holding anything up for that, but I'll note that, as it was last called as BCP, the IESG can decide to change the status without causing any delay to the document.

[Ballot comment]
I'm not yet recording a position on this document; I'd like to get a bit more info. The shepherd writeup says, "This document is not the product of any WG. It is AD sponsored. However, it has been reviewed by the OPSAREA and INTAREA WGs"

I went looking through the archives (Googling) and found this message (and its thread):

http://www.ietf.org/mail-archive/web/ipv6/current/msg19850.html

That had two reviews, one of which said, "I don't understand the motivation of the document" and the other of which said, "I'm not an expert on this stuff, but here are some comments." I couldn't find any other significant reviews, and importantly I couldn't find any messages that indicated this was important work that needed to be published as a BCP. Can someone give me some pointers to where this was actually discussed, and some indication that there is some consensus in the community that the AUP documented here is a good and necessary thing? It's fine if it's only a few experts (of which I am not one) think it's important to say this stuff and everyone else just shrugs and says, "Whatever". But I'd like to see some indication of that. I hope I'm just a bad googler.

[Ballot discuss]
There are three parts to my Discuss.

---

Section 2.1.1 reads strangely.

Your use of "appears" twice in the first paragraph is uncomfortable.

It is not advisable to state your understanding of how the use of
ICMP was adopted in the working group, and it is irrelevant. That
use of ICMP has IETF consensus and is in no way hidden in the
document.

It is fine to say that RPL should not be a model for future uses of
ICMP and so similar message types should not be defined in future.

Your observations about reliability and security guarantees in
routing protocol transport requirements miss the mark by a long way
(or is BGP the only routing protocol?). The two IGPs in common use
these days are designed to run over IP or native Ethernet and must
make their own provisions for reliability, while security is built
in to the protocols as much as acquired from IPsec. The main things
that ICMP gives RPL are a checksum, a protocol ID, and no requirement
to be encapsulated in UDP (I make no comment about which of those is
good).

Can I suggest:
OLD
  RPL, the IPv6 Routing protocol for low-power and lossy networks (see
  [RFC6550]) appears to be something of an outlier among the existing
  ICMP message types, as the expansion of its acronym appears to be an
  actual routing protocol using ICMP for transport.

  This should be considered anomalous and is not a model for future
  ICMP message types.  Our understanding is that the working group
  initially defined a discovery protocol extending existing ICMPv6
  Neighbor Discovery messages before moving to its own native ICMP
  type.

  It is typically the case that routing protocols have transport
  requirements that are not met by ICMP.  For example, there will be
  reliability guarantees and security guarantees that are not provided
  by ICMP, forcing protocol developers to design their own mechanisms.
  Given the availability of other IETF standard transports for routing,
  this reinvention should be avoided.
NEW
  RPL, the IPv6 Routing protocol for low-power and lossy networks (see
  [RFC6550]) uses ICMP as a transport.

  This should be considered anomalous and is not a model for future
  ICMP message types. That is, ICMP is not intended as a transport for
  other protocols and should not be used in that way in future
  specifications.
END

---

I really take issue with quite a bit of the content of section 4. As the
authors observe...
  this may serve to
  muddle the differences even further.  Ultimately the difference may
  not matter that much
...perhaps it would be wiser to leave out what is a disctraction fom the
main AUP.

But, in case the authors prefer to try to address my gripes...

1. There is a difference between a plane and a protocol that this text
  does not show. Indeed it seems to use the word "plane" to mean
  "protocol".

2. The term "layering" in telecommunications networks is not usually
  used to refer to this separation of function, but to either protocol
  layering (a la OSI model) or technology layering (that leads to
  network layering). The control plane and management plane are not
  layers but may utlise network partitions (sometime in band and
  sometimes physical).

3. The references to [I-D.ietf-opsawg-oam-overview] and [RFC6192] are
  somewhat arbitrary. It is true that the referenced documents provide
  descriptions, but are they normative?

4. It will be a surprise to people running routing protocols to find
  that they do notform part of the control plane.

5. I think if you were to observe (as you sort of do) that control plane
  interactions are between nodes for the purpose of operating the
  network, while management plane interactions are between nodes and
  external boxes for the same purpose, you would get closer to the
  truth.

6. Since you reference [I-D.ietf-opsawg-oam-overview] you might usefully
  spend time describing OAM protocols and their purposes. You could
  note that OAM protocols typically run in the data plane yet serve the
  purpose of control and management plane protocols. Then you could
  observe that ICMP is an OAM protocol, and move on.

7. Your final sentence reads...
    ICMP should not be used as a
    routing or network management protocol.
  ...which may be true, but I think you mean
    ICMP should not be used as a
    transport for any other protocol.

That last sentence notwithstanding (and it is already present in other
parts of the document) I strongly recommend to delete Section 4.

---

Section 5

  From a security perspective, ICMP plays a part in the Photuris
  protocol.

Reference please.

IESG/Authors/WG Chairs:

IANA has reviewed draft-shore-icmp-aup-06, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (An Acceptable Use Policy for New ICMP Types and Codes) to Best Current Practice


The IESG has received a request from an individual submitter to consider
the following document:
- 'An Acceptable Use Policy for New ICMP Types and Codes'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-11-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  In this document we provide a basic description of ICMP's role in the
  IP stack and some guidelines for future use.

  This document is motivated by concerns about lack of clarity
  concerning when to add new Internet Control Message Protocol (ICMP)
  types and/or codes.  These concerns have highlighted a need to
  describe policies for when adding new features to ICMP is desirable
  and when it is not.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-shore-icmp-aup/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-shore-icmp-aup/ballot/


No IPR declarations have been submitted directly on this I-D.