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

"Fred L. Templin" <> Tue, 24 April 2012 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5030C21F87F2 for <>; Tue, 24 Apr 2012 07:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.288
X-Spam-Status: No, score=-102.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LdHmTExP7u0v for <>; Tue, 24 Apr 2012 07:58:30 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id BDB2E21F87F4 for <>; Tue, 24 Apr 2012 07:58:28 -0700 (PDT)
Received: from [] by with NNFMP; 24 Apr 2012 14:58:27 -0000
Received: from [] by with NNFMP; 24 Apr 2012 14:58:27 -0000
Received: from [] by with NNFMP; 24 Apr 2012 14:58:27 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 33384 invoked by uid 60001); 24 Apr 2012 14:58:27 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1335279507; bh=2SOvEEwCfsECaMaSzfJuTPuyFDKguX/iJnlKC+7fsDY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=RRu5DhWaacXVTGgdHA0UkfH8nkjY1hT1yvnhRDb9LbJB/mLN43iQokCVKVOJkh4rqYDOlsQlzciEeGAmVcftlrQY7m8pg5NCyQnN+lo4SgM8wm8gFdBvrm4u6Qb1dCePEgIFRSo0XDTRF7fHeWHjA++bTgA4wJq5nawuDPKmOHg=
X-YMail-OSG: IoftIhYVM1lWs4PCp_3JF435KX7UKMmpvT1OJVCSXSZFHqf ri9Gy1prQqKCvS1IBTnEtMJ7qGPCv3rnFnyXn9LQlT4Dn9z4jCx2_egzVRC1 PaFugya1VD7f2LFcOf7XMD9ivhWjfOPxyeMflgajpnE0GVOyEFP7Okuu7so0 k7iKO9.umf8o0N_kL_.kY0P7Kr__EGvcn3_xyxBpzhqxHLZpow4tuN1QzK0k 4r8.fgXVh.KvYeliCyDa4p7GxEv.VqJ16nyJNF_bHHazSjnaCsnumTypDPah iXST_qBMCNbKm8k5p55nolHiS6_EBJaWsvzpfFffDPyPupRecv0Vcjzc3fDm Y_5OGegsSP.BDiWNGSUU19sqGPoXjKsAa9U50joZmWS._.31QtdMqW3RSKmj c2qySWn0Mh_hIBilvCJwdQ27bKpxruzNN0MHU8EX1E1d5xpNYm95vA2Ufv6U QZgZgIfTCudyJF0gcEgtfsrIbPHCOWSqYjJ8gVZYF66TktPE-
Received: from [] by via HTTP; Tue, 24 Apr 2012 07:58:27 PDT
X-RocketYMMF: fltemplin
X-Mailer: YahooMailWebService/
References: <>
Message-ID: <>
Date: Tue, 24 Apr 2012 07:58:27 -0700
From: "Fred L. Templin" <>
To: Pete McCann <>, "" <>, "" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-2012143828-282926690-1335279507=:26159"
X-Mailman-Approved-At: Tue, 24 Apr 2012 08:01:01 -0700
Subject: Re: [Gen-art] Gen-ART Telechat Review of draft-templin-aero-10
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: "Fred L. Templin" <>
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Apr 2012 14:58:31 -0000

Hello Pete,

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


> From: Pete McCann <>
>Sent: Monday, April 23, 2012 9:42 PM
>Subject: Gen-ART Telechat Review of draft-templin-aero-10
>I am the assigned Gen-ART reviewer for this draft. For background on
>Gen-ART, please see the FAQ at
>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.

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.

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

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

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

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

>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

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

>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

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

>Section 5:
>You say there are no IANA considerations, but do you need an experimental
>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.