Subject: [Gen-art] Gen-ART Telechat Review of draft-templin-aero-10

From: Pete McCann <[email-masked]>
Date: Tue, 24 Apr 2012 00:42:45 -0400

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-templin-aero-10
Reviewer: Peter McCann
Review Date: 2012-04-23
IETF LC End Date:
IESG Telechat date: 2012-04-26

Summary: Discuss

Major issues:

Section 4.1 attempts to provide some motivation for this draft:
   In many AERO link use case scenarios (e.g., small enterprise
   networks, small and stable MANETs, etc.), routers can engage in a
   classical dynamic routing protocol (e.g., OSPF, RIP, IS-IS, etc.) so
   that routing/forwarding tables can be populated and standard
   forwarding between routers can be used.  In other scenarios (e.g.,
   large enterprise/ISP networks, cellular service provider networks,
   dynamic MANETs, etc.), this might be impractical due to routing
   protocol control message scaling issues.
However, it isn't clear to me that the mechanisms proposed in this draft
would be any more scalable than existing dynamic routing protocols.

In general, the draft appears to be mixing the concepts of service provider
and end-user networks in strange ways.  The AERO link uses host-based
mechanisms for prefix delegation, but it is intended to be a backbone of
a service provider network.  There seem to be some trust assumptions
borrowed from access links (such as the need for ingress filtering), yet
the routers on the AERO link are expected to work together in a peer-to-
peer fashion to compute direct routes to each other.  I do not feel that the
draft has adequately motivated this somewhat quirky set of assumptions.
Perhaps a deployment example that motivates why the different edge
routers cannot trust each other is in order.

Minor issues:

Section 4.4.5:
The text says to use experimental type code "100" but the ASCII art
still says "137."  Does the figure need to be changed?

Section 4.4.12:
   Eventually, any such correspondent AERO nodes will receive a NULL
   AERO Redirect message and will cease to use the egress node ('D') as
   a next hop.  They will then revert to sending packets destined to the
   EUN node ('E') via a trusted intermediate router and may subsequently
   receive new AERO Redirect messages to discover that the EUN node ('E'
   ) is now associated with a new AERO edge router.
Seems like this scenario requires that *part* of a prefix that was delegated
to D is now re-routed by the intermediate router A to a different destination.
Is that correct?  You are proposing to punch a hole in the original allocation,
and put in a more-specific (perhaps host-specific) route to E through a new
path?  What kind of protocols would be used to establish this new forwarding
state?

Nits/editorial comments:

Section 4.4.4:
   Note that on links in which link-layer address spoofing is possible,
   AERO nodes may be obliged to require the use of digital signatures.
   In that case, only the third of the above conditions can be accepted
   in order to ensure adequate data origin authentication.
Did you mean to say "only the fourth of the above conditions can be
accepted..."?

Section 5:
You say there are no IANA considerations, but do you need an experimental
ICMPv6 type code allocated?

---

From: "Fred L. Templin" <[email-masked]>
Date: Tue, 24 Apr 2012 07:58:27 -0700 (PDT)

Hello Pete,

Thank you for your comments, and please see below for proposed resolutions:

Fred
[email-masked]

>________________________________
> From: Pete McCann <[email-masked]>
>To: [email-masked]; [email-masked] 
>Sent: Monday, April 23, 2012 9:42 PM
>Subject: Gen-ART Telechat Review of draft-templin-aero-10
> 

Scaling properties of the mechanism are proportional to
the number of distinct
(ingress, egress) pairs of active communications.
Intuitively, the mechanism will
provide better scaling properties than
traditional dynamic routing protocols if
the number of active pairs is sparse
in relation to the number of nodes on the
link. Quantitative analysis would be
through experimentation after publication.

>routers cannot trust each other is in order.

A deployment example could be added as a new Section
4.4 (causing existing
Sections 4.4 onward to be renumbered beginning with
Section 4.5). The new
Section could read:
 
“As a simple example, consider a large service provider
network that is extended
primarily using L2 bridges instead of L3 routers. The
network is therefore seen as
a single link by the IP layer. In that case, a new
spoofing attack vector is open to
malicious nodes on the link that could send
packets with spoofed IP source
addresses with low probability of detection,
e.g., to initiate a DoS attack directed
to some other node on the link. AERO
therefore applies to links on which attached
nodes do not necessarily trust
each other.”

>still says "137."  Does the figure need to be changed?

Yes; the figure is incorrect, and will be corrected to say "100".

>path?  What kind of protocols would be used to establish this new forwarding

Punching a hole in a short aggregated prefix is one
possibility, but another
possibility is that the edge router is delegated many
non-aggregated long
prefixes. In that case, the mobile node can take its long
prefix to a new
edge router without the old edge router needing to punch any
holes.

>Did you mean to say "only the fourth of the above conditions can be

You are correct; this was also mentioned in an earlier comment and
will be fixed in the next document version.

>ICMPv6 type code allocated?

No new experimental ICMPv6 code type needs to be
allocated, since RFC4443
sets aside the value “100” as an experimental ICMPv6
code point.