Asymmetric Extended Route Optimization (AERO)
draft-templin-aero-12

[Ballot comment]
I've cleared my Discusses.  Thanks for addressing those points.

1. (fixed in rev -11)

2. (addressed in response from author)

3. (fixed in rev -11)

4. (was Discuss 1) I think some text is needed in section 6.4.7 to
allow for the scenario suggested in this text from the Introduction:

  For example, when an ingress link neighbor accepts an ordinary
  redirection message, it has no way of knowing whether the egress link
  neighbor is ready and willing to accept packets directly without
  involving an intermediate router

The text in section 6.4.7 seems to assume that the egress node will
always be willing to accept traffic from the ingress node.  Fred
explained in e-mail that the egress node can passively ignore the
Predirect message by not sending a response Redirect message.
However, section 6.4.7 does not explicitly note that the egress node
can implement this behavior.

5. (was Discuss 2) I suggest s/involving/forwarding through/ for
clarification.

6. (was Discuss 3) In section 6.4.8, what is the advantage to the
intermediate router snooping the Redirect response and "relaying" the
Redirect on to the ingress node without decrementing the hop count,
rather than what would seem to be a less unusual method in which the
egress node sends the Redirect to the intermediate router, which
receives and processes the Redirect, and then sends a corresponding
Redirect on to the ingress node?

7. (was Discuss 4) Fixed in rev -11.

[Ballot comment]
Thanks to the author for providing some cocrete examples and motivation, and for moving the experiment to operate over UDP. This addresses my Discuss and I am happy to ballot "yes" and encourage this experiment.

I would be interested to hear from the author how he sees the applicability of this work to data centers and the NVO3 working group.

[Ballot comment]
FWIW, I (still) agree with a bunch of the the other discusses on this.

You've now stated that the signature scheme is for future study,
which is ok for me for an experimental document like this. However,
as a comment, I'm still not keen on how 6.4.4 is written right now.
It says: you're ok if one of 4 things, but how to achieve the last
one (signatures) is not defined here, yet you say "may be
obliged" for that.

I'd suggest getting rid of the 4th bullet entirely and making the
following change (or similar) at the end:

OLD

  Note that on links in which link-layer address spoofing is possible,
  AERO nodes may be obliged to require the use of digital signatures
  applied through means outside the scope of this document.  In that
  case, only the fourth of the above conditions can be accepted in
  order to ensure adequate data origin authentication.

NEW

  Note that on links in which link-layer address spoofing is possible,
  (which is common) AERO nodes will not be very secure since
  the data origin authentication defined here is easily spoofed. To
  address this, future work might define a strong data origin
  authentication scheme (such as the use of digital signatures) to
  address this problem.

[Ballot comment]
Looking at the number of DISCUSS already, I would prefer to wait for the next version of the draft before reviewing the document in details. By spending 15 minutes on the draft, I have some questions already. Therefore, I reserve the option to come back and potential add a DISCUSS on the next document version.

[Ballot discuss]
It is entirely unclear to me what real problem this work is designed to
solve.

It is clear that it is possible to construct a network where "triangular
paths" could exist and where redirection can help resolve the issues.

Only one brief paragraph is given to explain why "ordinary redirection
may lead to operational issues on certain link types and/or in certain
deployment scenarios" and it is unclear to me whether this represents a
real problem. It would appear that the issue can arrise when the multi-
access link has very large numbers of hosts and very large numbers of
routers on the same link. Is this realistic? Do we not find this type
of deployment in the wild because of these problems or because that is
simply not how networks are usually built?

So I would like to see several things called out more explicitly:

- What are the deployments that motivate this work?

- Is the model here that the Aero Edge Routers are acting as "PEs" in
  a sort of VPN like model?

- What sort of scaling numbers are to be considered?

- What are the operational problems with existing solutions and why
  can they not be solved using pre-existing protocol solutions?

- Would the problem not exist if all nodes on the link were routers
  or if nearly all (i.e. except for a default and alternate router)
  were hosts?

- How come spoofing of redirects is given as a motivation for this
  work yet called out as a security issue for Aero with a remediation 
  offered that could be applied today?

Other than that, I feel that there are so many significant changes
needed to address the many Discusses already raised that I am cautious
about drawing a line under my review and reserve the option to come back
and add to my Discuss when a future version has been published. I hope
the sponsoring AD will put the document back on a future telechat after
it has been updated.

[Ballot comment]
In Figure 5, I assume that nodes B and F are actually routers (i.e. AERO
edge routers) since they provide acceess to hosts through IP clouds.

[Ballot discuss]
Hate to pile on but there were a number of agreed changes as a result of the secdir review.  This is just a placeholder discuss until fixes to those changes are agreed and incorporated.

[Ballot comment]
Lots of DISCUSS positions already, and I don't have anything new to add.  I'll just say that I support some of the other AD's DISCUSS positions, particularly Brian's and Ron's.

[Ballot discuss]
- It is impossible to evaluate this draft without more detail regarding the operational scenario in which it is to be deployed. If the reference scenario described in Section 4.3 were deployed by devices and links contained within a single campus, one might ask why the problem could not be solved by running an IGP on Routers A, B and D and by putting Host F behind a router.

- This draft appears to use ICMP as a routing protocol. However, ICMP does not have all of the capabilities required by a routing protocol. You might want to explore the this issue in the next version of this draft.

- The approach used in this draft seems to contradict the following statement from RFC 1812:

"A router using a routing protocol (other than static routes) MUST NOT consider paths learned from ICMP Redirects when forwarding a packet. If a router is not using a routing protocol, a router MAY have a configuration that, if set, allows the router to consider routes learned through ICMP Redirects when forwarding packets."


- Beyond these, there are many other comments. For example, Stephen's question regarding authentication is telling. However, it may not be worth discussing these until we understand the problem that you are really trying to solve.

[Ballot discuss]
(1) 4.4.4 - I don't get the origin authentication check, you
say that the source address is correct if a list of 4 things are ok,
but then later that only one of them needs to be ok. Which is it?  The
latter case (any of the 4) seems broken since the 3rd bullet is just
the easily spoofed MAC address. The last paragraph here is also
odd, the two sentences seem to contradict one another.

(2) the signature scheme in 4.4.4 is undefined, you need to either
define it, or else fess up and say that there's no current scheme
and AERO just depends on things that are easily forged and strong
data origin authentication is for future work. (I'd be ok with
the latter for an experimental draft like this I think.)
section 3: no security requirements for strong authentication?

[Ballot discuss]
I am editing my DISCUSS points in order focus on the issues that still need resolving.  Since a new document is not available, I have marked each point with the state I think they are in...

This document is going to require some true DISCUSSion in order to resolve some obvious issues.

1. If this draft goes forward as Experimental, it needs more justification.  What issues with AERO make it unsuitable for use on the Internet as a whole?  What network characteristics are required to assess AERO's behavior?  What issues will arise if non-AERO and AERO-capable nodes attempt to interact?  Is AERO truly suitable for any multi-access network?

2. From the author, my understanding is that an AERO edge router will have a set of ACLs that only allow traffic to be forwarded to it that comes from its default router (router D only forwards traffic from router A by default). That implies that router D must trust the MAC-level information (e.g., src MAC address) contained in a forwarded frame.  How is that accomplished?  In general, multi-access networks require specific MAC-level functions to do that.  Discussion of these issues and how they relate to the AERO messages is needed.

3. [Resolved pending a new version] Section 4.2.2 specifies AERO host behavior.  Since that behavior does not differ from standard IPv6 host behavior defined in RFC 4861 and RFC 4862, what is the purpose?  *IF* you need to say anything about host behavior, state that it acts as an IPv6 host (as defined in RFCs 4861, 4862, and 6434).

4.[Resolved pending a new version] Do AERO edge routers (Section 4.2.3) differ from the CPE routers defined in RFC 6204 (other than the added AERO functionality)?  It appears that they should, but it is not specifically called out.

5.[Modified] I find the claim (section 4.4.1) that "...the ingress node has no way of knowing whether the egress is willing to accept its packets, ..." dubious at best. These packets are being transmitted as IP datagrams, which are best effort.  It is not the job of layer-3 to build reliability into the packet forwarding paradigm.

6. [Resolved] Section 4.4.5 re-defines the structure of the ICMPv6 Redirect message by adding new bit fields.  Given that, why does the document not list itself as updating RFC 4861?  If that is the case, this change needs to be reviewed by the 6MAN working group.

7. [Modified] Sections 4.4.10-12 have convinced me that this specification is really a dynamic routing protocol using ICMPv6 Redirect (and the variant Predirect) messages. The incorporation of mobility concepts and periodic reachability logic makes this no different than existing MANET and scaled-down IGPs.  In this light, the document does not clearly explain key functional behaviors or why those behaviors are not needed. In order to address these concerns, more detail is needed (per Russ' DISCUSS) on exactly what link types AERO is expected to work under.  Single-link behavior for something like Ethernet does not make sense in the context of AERO.

[Ballot comment]
1. [Resolved pending a new version] Section 4.2.2 states that the egress AERO router sends a Redirect message to the intermediate AERO router who then proxies that Redirect to the ingress AERO router. It would be good to include a forward pointer to sections 4.4.7 and 4.4.8 since that is where the sending and redirect rules are defined.

2. [Resolved pending a new version] The Acknowledgments section seems to have been truncated.

[Ballot discuss]
1. In this text from the Introduction:

  For example, when an ingress link neighbor accepts an ordinary
  redirect message, it has no way of knowing whether the egress link
  neighbor is ready and willing to accept packets directly without
  involving an intermediate router.

I don't think I see any description of a way for the egress node to
explicitly notify the ingress node, either directly or through the
intermediate node, that the egress node is unwilling "to accept
packets directly", nor do I see how the intermediate node reacts to a
NAK from the egress node.

2. Also in the text cited in point 1, I don't see any support for the
assertion that an intermediate router is required.  Isn't that what
routing protocols do?

On re-reading that text, I realize I may be confused: does "without
involving an intermediate router" mean:

a) the ingress node needs an intermediate router to learn whether the
egress nodes will accept traffic from the ingress node or
b) the egress node will not accept traffic directly from the ingress
node but it will accept traffic forwarded from the ingress node
forwarded through the intermediate node?

3. Do I have it right in section 4.4.7 that the Redirect response from
D is sent to L3(B) (i.e., unicast to the ingress node), but the
intermediate node A snoops that Redirect message and verifies the
contents in various ways before forwarding it to B?  And then it
doesn't decrement the hopcount?  Why are these exceptional forwarding
rules necessary?  Can't D send the Redirect to A, and then A send a
corresponding Redirect to B?

4. Section 4.4.5 specifies that the AERO Predirect/Redirect message
will use type 100, while Figure 4 shows the use of type 137. I include
this as a DISCUSS point because Figure 4 needs to be fixed to show
type 100 before the document is published to avoid problems with the
existing ICMP Redirect message.

[Ballot comment]
1. The document has many details about the operations of the various
AERO nodes that are not germane to the specification of AERO.  I would
suggest editing out all of the provisioning and initialization details
in, e.g., section 4.3, and simply describe the state of the various
AERO nodes at the time of AERO operation.

2. In section 4.4.11, what prevents A from invoking the
Predirect/Redirect mechanism for each datagram received from B
destined for D, even if B has determined that B cannot send directly
to D?

3. In the Security Considerations section, how does an Aero edge node
know to trust an AERO intermediate router that advertises itself?  I
think the digital signature mechanism needs to be explored in more
detail or data authentication more generally needs to be left for
future work.

[Ballot discuss]

  I understand that the AERO mechanisms were initially designed for NBMA
  tunnel virtual interfaces, but these mechanisms can also be applied to
  any multiple access link types that support redirection.  That said, I
  think we need to better characterize the environments where AERO is
  appropriate, and maybe even more importantly the environments where
  AERO is not appropriate.

  This position seems to be supported by the Gen-ART Review by
  Pete McCann on 24-Apr-2012.  Please consider the other comments that
  are include in this review.  The review can be found at:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07385.html

[Ballot comment]
I agree with Brian's DISCUSS regarding status. In fact, even Experimental seems a bit odd. The document doesn't describe the circumstances under which you would want to experiment and why you wouldn't want to let this out on the Internet as a proposed standard. I think some more explanation, and perhaps an adjustment to status, is needed.

[Ballot discuss]
This document is going to require some true DISCUSSion in order to resolve some obvious issues.

1. Why is the document labeled INFORMATIONAL when it is clearly specifying a new protocol behavior?  It contains the boilerplate text for the 2119 keywords and it uses those words (albeit some are in lowercase) to mandate actions.  Should this really be EXPERIMENTAL?  This is especially relevant given that the header says Experimental, section 4.4.14 refers to this document as an experimental specification, and it is using the Experimental code points for ICMPv6 messages.

2. The logic argued as to why this functionality is required is flawed.  The Introduction argues that ingress and egress nodes do not know if the other node is authorized to forward traffic from/to the source/destination networks. Wrapping this authorization concept into modified Redirect messages seems convoluted and outside the scope of ICMP messages.

3. Section 4.2.2 specifies AERO host behavior.  Since that behavior does not differ from standard IPv6 host behavior defined in RFC 4861 and RFC 4862, what is the purpose?  *IF* you need to say anything about host behavior, state that it acts as an IPv6 host (as defined in RFCs 4861, 4862, and 6434).

4. Do AERO edge routers (Section 4.2.3) differ from the CPE routers defined in RFC 6204 (other than the added AERO functionality)?  It appears that they should, but it is not specifically called out.

5. I find the claim (section 4.4.1) that "...the ingress node has no way of knowing whether the egress is willing to accept its packets, nor whether the egress is even reachable via a direct path..." dubious at best.  RFC 4861 (section 7.3.3) specifically calls out that the creation of a Neighbor Cache entry based on a Redirect marks that entry as STALE.  That state requires the node to perform neighbor reachability tests before the entry can be used.  And the follow-on claim that an ingress node does not know if the final destination has moved away from the egress node applies to more than just redirection scenarios.  That issue is also present in environments where dynamic routing protocols are run as well.

6. Section 4.4.5 re-defines the structure of the ICMPv6 Redirect message by adding new bit fields.  Given that, why does the document not list itself as updating RFC 4861?  If that is the case, this change needs to be reviewed by the 6MAN working group.

7. Sections 4.4.10-12 have convinced me that this specification is really a dynamic routing protocol using ICMPv6 Redirect (and the variant Predirect) messages. The incorporation of mobility concepts and periodic reachability logic makes this no different than existing MANET and scaled-down IGPs.  In this light, the document does not clearly explain key functional behaviors or why those behaviors are not needed.

[Ballot comment]
1. Section 4.2.2 states that the egress AERO router sends a Redirect message to the intermediate AERO router who then proxies that Redirect to the ingress AERO router. It would be good to include a forward pointer to sections 4.4.7 and 4.4.8 since that is where the sending and redirect rules are defined.

2. The Acknowledgments section seems to have been truncated.

State changed to In Last Call from Last Call Requested

The following Last Call Announcement was sent out:

From: The IESG

To: IETF-Announce

Reply-To: ietf@ietf.org

Subject: Last Call:  (Asymmetric Extended Route Optimization (AERO)) to Informational RFC





The IESG has received a request from an individual submitter to consider

the following document:

- 'Asymmetric Extended Route Optimization (AERO)'

  as an Informational RFC



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 2012-04-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





  Nodes attached to common multi-access link types (e.g., multicast-

  capable, shared media, non-broadcast multiple access (NBMA), etc.)

  can exchange packets as neighbors on the link, but may not always be

  provisioned with sufficient routing information for optimal neighbor

  selection.  Such nodes should therefore be able to discover a trusted

  intermediate router on the link that provides both forwarding

  services to reach off-link destinations and redirection services to

  inform the node of an on-link neighbor that is closer to the final

  destination.  This redirection can provide a useful route

  optimization, since the triangular path from the ingress link

  neighbor, to the intermediate router, and finally to the egress link

  neighbor may be considerably longer than the direct path from ingress

  to egress.  However, ordinary redirection may lead to operational

  issues on certain link types and/or in certain deployment scenarios.

  This document therefore introduces an Asymmetric Extended Route

  Optimization (AERO) capability that addresses the issues.









The file can be obtained via

http://datatracker.ietf.org/doc/draft-templin-aero/



IESG discussion can be tracked via

http://datatracker.ietf.org/doc/draft-templin-aero/ballot/





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

Proto Statement for draft-templin-aero

(1) As indicated on the title page, this writeup accompanies a
request for publication of the subject document as an
Experimental RFC.

(2) 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:

(3) The document shepherd provided review comments on the focus
and clarity of earlier versions of this document.  He provided
significant review of all the material in later versions, and
is satisfied that the current document is sound material worthy
of publication by the IESG as an Experimental RFC.

(4) In the document shepherd's opinion, there have been sufficient
reviews to warrant IETF last call and IESG consideration of this
document.  The shepherd assumes that normal last-call reviews
will be provided to ensure that sufficient eyes have checked
the document.

(5) The document proposes specific routing related mechanisms,
and contains significant security usages.  Both of these
should be formally reviewed by the relevant areas as part
of the IETF Last Call process. The shepherd has examined
both aspects, and is of the opinion that the work is sound
in both regards.

(6) The document shepherd does not have any concerns that
need to be considered or addressed regarding this document.

(7) The author has confirmed that there is no undisclosed
IPR known to the author to apply to this document.

(8) There are no IPR disclosures relevant to this document.

(9) This document is the work of the author, and does
not represent nor have the support of any particular community.

(10) There is no known discontent with this document.
Neither the author nor the document shepherd know of any
issues that would lead to appeals.

(11) The document complies with IETF rules for ID content
and form.  The tool is unhappy with the way RFC 2119
terminology is used, but the shepherd is satisfied that
the construction is clear.

(12) There are no formal reviews associated with any
content in this document.

(14) There no issues with the references in the document.
All normative references are to existing, published, RFCs.

(15) There are no downref issues with this document.

(16) This experimental document will not change the
status of any other documents.

(17) The document does not create any new IANA registries
or add entries to any existing entries.  Earlier
informational versions of this document used bits from
a field defined in existing standards track RFCs, but for
which there are no registries.  Using an experimental
ICMPv6 code point for the messages defined in this
document removes the complications the absence of such
a registry causes.

(18) This document does not create any IANA registries.

(19) There is no formal language content in this document,
and therefore there was no review of such.

Summary for final publication:

Technical Summary
  This document provides an experimental approach to using
  redirection based exchanges in order to securly provide for
  efficient forwarding of IPv6 messages over certain classes
  of classes of multiple access link topologies.  In those
  environments, it replaces significantly complex routing
  protocol interactions with controlled redirection.

Working Group Summary
  This document is an independent document, not reviewed
  by any IETF Working group.

Document Quality
  There are no current implementations of this protocol.
  The document shepherd and sponsoring AD have both
  provided significant review and comments which have
  been incorporated by the author.

Personnel
  The document shepherd for this document is Joel M. Halpern.
  The  sponsoring AD for this document is Stewart Bryant