IP Router Alert Considerations and Usage
draft-ietf-intarea-router-alert-considerations-10

[Ballot comment]
(I would like these two changed, but I won't hold up the document over them.)

1. I think this document would do fine as a standards track document instead of a BCP.

2. The use of the phrase "MAY be safely deployed" in 4.2.2 seems like an inappropriate use of the term "MAY". It's not specifying a protocol option. I think what you mean is "can be safely deployed".

[Ballot discuss]
This is an updated discuss based on -09

Doesn't this document update RFC 2113 and 2711?  If this document is all about security considerations of something defined in those two documents doesn't it update that document?

* If this document is updating 2113 and 2711 we should add that to the header to help implementers:

Updates: 2113, 2117 (if approved)

[Ballot discuss]
The way 2119 terminology is used in this document is problematic. Three general issues:

1. The document says "it is RECOMMENDED", in the passive voice, instead of saying who should be doing what. This occurs twice in section 4.3 and twice in section 5. The current phrasing I fear will confuse implementers and obscures what the document is actually requiring.

2. The use of the phrase "MAY be safely deployed" seems like an inappropriate use of the term "MAY". That doesn't seem to be specifying a protocol option. I think what you mean is "can be safely deployed". This occurs in 4.2.1 three times and 4.2.2 three times.

3. In section 4.3:

  As a last resort, if the SP does not have any means to safely
  transport end to end IP Router Alert option packets over his network,
  the SP MAY drop those packets.

That "MAY" seems odd as the other choices are given as examples (not protocol options) in the preceeding three paragraphs. Also, because this is a "last resort" with "undesirable consequences", it seems that it is not a real option as much as something that the SP SHOULD NOT do except as a "last resort". Again, using the word "can" would work here, or it ought to be rewritten with the "SHOULD NOT".

[Ballot discuss]
[Update 2011-07-28: I see in -06 that the example I gave in #1 below has been fixed, but none of the other similar places I cited in the document were changed, and nothing in #2 or #3 has been changed. If the WG does not feel that my requests are reasonable, I'd like to hear that. But I have not heard anything from the author, chairs, or shepherd regarding this DISCUSS.]

The way 2119 terminology is used in this document is problematic. Three general issues:

1. The document repeatedly says "it is RECOMMENDED", in the passive voice, instead of saying who should be doing what. For example, in 4.1:

  Thus, it is RECOMMENDED that applications and protocols not be
  deployed with a dependency on processing of the Router Alert option
  (as currently specified) across independent administrative domains in
  the Internet.

(This one has the additional problem that the recommendation is *not* to do something, making it more confusing.) It seems to me much better to rewrite this as:

  Thus, applications and protocols SHOULD NOT be deployed with a
  dependency on processing of the Router Alert option (as currently
  specified) across independent administrative domains in the Internet.

If for some reason you want to use the term "RECOMMENDED" and stick to the passive voice (which I would wonder about because it is identical to using the term "SHOULD"), you could try:

  Thus, deployment of applications and protocols with a dependency on
  processing of the Router Alert option across independent
  administrative domains in the Internet is NOT RECOMMENDED.

The same sort of thing appears twice in section 4.3 and twice in section 5. The current phrasing I fear will confuse implementers and obscures what the document is actually requiring.

2. The use of the phrase "MAY be safely deployed" seems like an inappropriate use of the term "MAY". That doesn't seem to be specifying a protocol option. I think what you mean is "can be safely deployed". This occurs in 4.2.1 three times and 4.2.2 three times.

3. In section 4.3:

  As a last resort, if the SP does not have any means to safely
  transport end to end IP Router Alert option packets over his network,
  the SP MAY drop those packets.

That "MAY" seems odd as the other choices are given as examples (not protocol options) in the preceeding three paragraphs. Also, because this is a "last resort" with "undesirable consequences", it seems that it is not a real option as much as something that the SP SHOULD NOT do except as a "last resort". Again, using the word "can" would work here, or it ought to be rewritten with the "SHOULD NOT".

A similar thing applies to the MAYs in the first and last paragraphs of section 5. They appear to be examples, not protocol options.

[Ballot comment]
I support Sean's DISCUSS about the document updating the Security Considerations sections of the RAO defining documents.

I support Ron's DISCUSS.

I support Wesley's COMMENT. Actually I think it has almost a DISCUSS value, as the document makes distinction in a few places between processing (and not only speed of processing) on the fast path and slow path.

[Ballot discuss]
Doesn't this document update RFC 2113 and 2711?  If this document is all about security considerations of something defined in those two documents doesn't it update that document?

I think the security considerations ought to be tweaked a bit to note that 2311 and 2711 originally defined the RAO and included some security considerations:

This document expands the security considerations of [RFC2113] and [RFC2711], which defined the RAO, to discuss security risks associated with current usage of the IP Router Alert Option and associated practices.  See [RFC4081] for additional security considerations.

[Ballot discuss]
The way 2119 terminology is used in this document is problematic. Three general issues:

1. The document repeatedly says "it is RECOMMENDED", in the passive voice, instead of saying who should be doing what. For example, in 4.1:

  Thus, it is RECOMMENDED that applications and protocols not be
  deployed with a dependency on processing of the Router Alert option
  (as currently specified) across independent administrative domains in
  the Internet.

(This one has the additional problem that the recommendation is *not* to do something, making it more confusing.) It seems to me much better to rewrite this as:

  Thus, applications and protocols SHOULD NOT be deployed with a
  dependency on processing of the Router Alert option (as currently
  specified) across independent administrative domains in the Internet.

If for some reason you want to use the term "RECOMMENDED" and stick to the passive voice (which I would wonder about because it is identical to using the term "SHOULD"), you could try:

  Thus, deployment of applications and protocols with a dependency on
  processing of the Router Alert option across independent
  administrative domains in the Internet is NOT RECOMMENDED.

The same sort of thing appears twice in section 4.3 and twice in section 5. The current phrasing I fear will confuse implementers and obscures what the document is actually requiring.

2. The use of the phrase "MAY be safely deployed" seems like an inappropriate use of the term "MAY". That doesn't seem to be specifying a protocol option. I think what you mean is "can be safely deployed". This occurs in 4.2.1 three times and 4.2.2 three times.

3. In section 4.3:

  As a last resort, if the SP does not have any means to safely
  transport end to end IP Router Alert option packets over his network,
  the SP MAY drop those packets.

That "MAY" seems odd as the other choices are given as examples (not protocol options) in the preceeding three paragraphs. Also, because this is a "last resort" with "undesirable consequences", it seems that it is not a real option as much as something that the SP SHOULD NOT do except as a "last resort". Again, using the word "can" would work here, or it ought to be rewritten with the "SHOULD NOT".

A similar thing applies to the MAYs in the first and last paragraphs of section 5. They appear to be examples, not protocol options.

[Ballot comment]
1) You might want to find another word for "punt". This word may not be understood by those not familiar with American Football or Rugby.

[Ballot discuss]
I intend to change this from a DISCUSS to YES as soon as a few minor changes are made.

s/network operators need to actively protect themselves against externally generated IP Router Alert packets/network operators SHOULD actively protect themselves against externally generated IP Router Alert packets

s/ Thus, it is RECOMMENDED that applications and protocols not be deployed with a dependency on processing of the Router Alert option (as currently specified) across independent administrative domains in the Internet./  Thus, applications and protocols MUST NOT be deployed with a dependency on processing of the Router Alert option  (as currently specified) across independent administrative domains in the Internet.

- In Section 4.2.2, just above Figure 4, you talk about a private enterprise network. Do you mean a VPN? Is there any chance of another enterprise (C) sending a RA Optioned Packet to Enterprise A? If so, should B deliver it?

- In the second part of section 4.2.2, you talk about "special agreements between administrative domains". More text is required. here. Let's say that A enters into an agreement with B. That's fine. Now let's say that B enters into an agreement with C. That's fine, so long as B tells A about the agreement with C. Now let's say that C enters into an agreement with D. Will D inform A? If not, the special agreement has been breached. I don't see this flying in the real world.

[Ballot comment]
The Gen-ART Review by Miguel Garcia on 13-Jul-2011 includes two
  editorial comments:

  - Make sure that "Router Alert Option" is written with capital "O"
    across the document. There are a few instances with a lower "o".

  - Expand acronyms at first occurrence. This includes: ASIC

[Ballot comment]
definition of fast-path should mention that this is the nominal processing path within a router for datagrams, and then the slow-path definition should say that this is a sub-nominal processing path for packets that require special processing or differ from assumptions made in fast path heuristics.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (IP Router Alert Considerations and Usage) to BCP


The IESG has received a request from the Internet Area Working Group WG
(intarea) to consider the following document:
- 'IP Router Alert Considerations and Usage'
  as a BCP

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 2011-07-13. 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


  The IP Router Alert Option is an IP option that alerts transit
  routers to more closely examine the contents of an IP packet.
  Resource reSerVation Protocol (RSVP), Pragmatic General Multicast
  (PGM), Internet Group Management Protocol (IGMP), Multicast Listener
  Discovery (MLD), Multicast Router Discovery (MRD) and General
  Internet Signalling Transport (GIST) are some of the protocols that
  make use of the IP Router Alert option.  This document discusses
  security aspects and usage guidelines around the use of the current
  IP Router Alert option.  Specifically, it provides recommendation
  against using the Router Alert in the end-to-end open Internet as
  well as identify controlled environments where protocols depending on
  Router Alert can be used safely.  It also provides recommendation
  about protection approaches for Service Providers.  Finally it
  provides brief guidelines for Router Alert implementation on routers.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-intarea-router-alert-considerations/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-intarea-router-alert-considerations/


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

State changed to AD Evaluation from Publication Requested.
I have reviewed this specification and found that it was well written, ready to move forward. I did have a few smaller issues, however.

Technical:

In Section 2:

The IPv4 base specification [RFC0791] defines a general notion of IPv4 options that can be included in the IPv4 header (without distinguishing between hop-by-hop versus end-to-end option).  The IPv4 Router Alert Option is one particular IPv4 option.  Similar security concerns to those discussed in the present document for the IPv4 Router Alert apply more generically to the concept of IPv4 option.  However, addressing the broader concept of IPv4 option thoroughly would require additional material so as to cover additional considerations associated with it (such as lack of option ordering, etc.), so this is kept outside the scope of the present document.

In fairness, I would probably tell the reader that other IPv4 options are often blocked in firewalls and not very widely used, so the risks they present are largely non-existent.

In Section 3

It can be observed that opening up a hole in the control plane of Service Provider routers is commonly done for other applications, such as BGP peering.

The phrase "opening up a hole" is somewhat imprecise. How about saying something like this: "Note that service providers commonly allow external parties to communicate with a control plane application in their routers, such as with BGP peering."

In Section 4:

This may (ideally) be achieved by tunneling IP Router Alert packets [RFC6178] so that the IP Router Alert option is hidden through that network, or it may be achieved via mechanisms resulting in occasional (e.g., rate limiting) or systematic drop of IP Router Alert packets.

To know exactly how "ideal" the tunneling approach is, we'd have to know what the cost of tunneling is (bandwidth, MTU errors, etc) vs. benefits from the Router Alert application. I would strike the word "ideally" from above.

Editorial:

In the abstract

> RSVP, PGM, IGMP/MLD, MRD and GIST are some of the protocols that make use of the IP Router Alert option.

It is customary to expand less-well known acronyms (PGM, MRD and GIST, for instance) in the abstract. And in Section 2 you expand GIST, but not others.

In Section 2:

> A proposal for such enhancements can be found in [I-D.narayanan-rtg-router-alert-extension].

I'd prefer to make it clearer that no agreed/approved proposal exists at this time. E.g., "One such proposal is discussed in [...], but at the time of this writing, the IETF has not adopted any extensions for this purpose."

  (1.a) Who is the Document Shepherd for this document? 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?

The Document Shepherd is Julien Laganier, INTAREA co-chair. He
        has personally done a thorough review of the document. He
        believe the document is ready for forwarding to IESG for
        publication.

  (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? 

        The document was given adequate reviews. The Document Shepherd has
        no concerns about the depth or breadth of these reviews.

  (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?

        The Document Shepherd has no such concerns.

  (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.

        The Document Shepherd has no such concerns.

  (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? 

There is WG consensus behind this document.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise 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.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        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?

Yes.

  (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].

The document has split its references into normative and
        informative. There are neither normative references in an unclear
        state, nor downward references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration 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 [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

        The document has an IANA considerations sections that correctly
state that the document does not need IANA actions.

  (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?

        There are no such sections.

  (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

  The IP Router Alert Option is an IP option that alerts transit
  routers to more closely examine the contents of an IP packet.  RSVP,
  PGM, IGMP/MLD, MRD and GIST are some of the protocols that make use
  of the IP Router Alert option.  This document discusses security
  aspects and usage guidelines around the use of the current IP Router
  Alert option.  Specifically, it provides recommendation against using
  the Router Alert in the end-to-end open Internet as well as identify
  controlled environments where protocols depending on Router Alert can
  be used safely.  It also provides recommendation about protection
  approaches for Service Providers.  Finally it provides brief
  guidelines for Router Alert implementation on routers.

    Working Group Summary

  The normal WG process was followed and the document as it stands now
  reflects WG consensus with nothing special worth mentioning.

    Document Quality

  The document was given adequate reviews. The Document Shepherd has
  no concerns about the depth or breadth of these reviews.