Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5030C21F87F2 for ; Tue, 24 Apr 2012 07:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.288 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdHmTExP7u0v for ; Tue, 24 Apr 2012 07:58:30 -0700 (PDT) Received: from nm31-vm1.bullet.mail.bf1.yahoo.com (nm31-vm1.bullet.mail.bf1.yahoo.com [72.30.239.9]) by ietfa.amsl.com (Postfix) with SMTP id BDB2E21F87F4 for ; Tue, 24 Apr 2012 07:58:28 -0700 (PDT) Received: from [98.139.212.153] by nm31.bullet.mail.bf1.yahoo.com with NNFMP; 24 Apr 2012 14:58:27 -0000 Received: from [98.139.212.215] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 24 Apr 2012 14:58:27 -0000 Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 24 Apr 2012 14:58:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 794887.38719.bm@omp1024.mail.bf1.yahoo.com Received: (qmail 33384 invoked by uid 60001); 24 Apr 2012 14:58:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; 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 [130.76.32.212] by web161603.mail.bf1.yahoo.com via HTTP; Tue, 24 Apr 2012 07:58:27 PDT X-RocketYMMF: fltemplin X-Mailer: YahooMailWebService/0.8.117.340979 References: Message-ID: <1335279507.26159.YahooMailNeo@web161603.mail.bf1.yahoo.com> Date: Tue, 24 Apr 2012 07:58:27 -0700 (PDT) From: "Fred L. Templin" To: Pete McCann , "gen-art@ietf.org" , "draft-templin-aero.all@tools.ietf.org" 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-BeenThere: gen-art@ietf.org 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 ---2012143828-282926690-1335279507=:26159 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Pete,=0A=0AThank you for your comments, and please see below for prop= osed resolutions:=0A=0AFred=0Afltemplin@acm.org=0A=0A>_____________________= ___________=0A> From: Pete McCann =0A>To: gen-art@ietf.or= g; draft-templin-aero.all@tools.ietf.org =0A>Sent: Monday, April 23, 2012 9= :42 PM=0A>Subject: Gen-ART Telechat Review of draft-templin-aero-10=0A> =0A= >I am the assigned Gen-ART reviewer for this draft. For background on=0A>Ge= n-ART, please see the FAQ at=0A>< http://wiki.tools.ietf.org/area/gen/trac/= wiki/GenArtfaq>.=0A>=0A>Please wait for direction from your document shephe= rd=0A>or AD before posting a new version of the draft.=0A>=0A>Document: dra= ft-templin-aero-10=0A>Reviewer: Peter McCann=0A>Review Date: 2012-04-23=0A>= IETF LC End Date:=0A>IESG Telechat date: 2012-04-26=0A>=0A>Summary: Discuss= =0A>=0A>Major issues:=0A>=0A>Section 4.1 attempts to provide some motivatio= n for this draft:=0A>=C2=A0=C2=A0=C2=A0In many AERO link use case scenarios= (e.g., small enterprise=0A>=C2=A0=C2=A0=C2=A0networks, small and stable MA= NETs, etc.), routers can engage in a=0A>=C2=A0=C2=A0=C2=A0classical dynamic= routing protocol (e.g., OSPF, RIP, IS-IS, etc.) so=0A>=C2=A0=C2=A0=C2=A0th= at routing/forwarding tables can be populated and standard=0A>=C2=A0=C2=A0= =C2=A0forwarding between routers can be used.=C2=A0 In other scenarios (e.g= .,=0A>=C2=A0=C2=A0=C2=A0large enterprise/ISP networks, cellular service pro= vider networks,=0A>=C2=A0=C2=A0=C2=A0dynamic MANETs, etc.), this might be i= mpractical due to routing=0A>=C2=A0=C2=A0=C2=A0protocol control message sca= ling issues.=0A>However, it isn't clear to me that the mechanisms proposed = in this draft=0A>would be any more scalable than existing dynamic routing p= rotocols.=0A=0AScaling properties of the mechanism are proportional to=0Ath= e number of distinct=0A(ingress, egress) pairs of active communications.=0A= Intuitively, the mechanism will=0Aprovide better scaling properties than=0A= traditional dynamic routing protocols if=0Athe number of active pairs is sp= arse=0Ain relation to the number of nodes on the=0Alink. Quantitative analy= sis would be=0Athrough experimentation after publication.=0A=0A>In general,= the draft appears to be mixing the concepts of service provider=0A>and end= -user networks in strange ways.=C2=A0 The AERO link uses host-based=0A>mech= anisms for prefix delegation, but it is intended to be a backbone of=0A>a s= ervice provider network.=C2=A0 There seem to be some trust assumptions=0A>b= orrowed from access links (such as the need for ingress filtering), yet=0A>= the routers on the AERO link are expected to work together in a peer-to-=0A= >peer fashion to compute direct routes to each other.=C2=A0 I do not feel t= hat the=0A>draft has adequately motivated this somewhat quirky set of assum= ptions.=0A>Perhaps a deployment example that motivates why the different ed= ge=0A>routers cannot trust each other is in order.=0A=0AA deployment exampl= e could be added as a new Section=0A4.4 (causing existing=0ASections 4.4 on= ward to be renumbered beginning with=0ASection 4.5). The new=0ASection coul= d read:=0A=C2=A0=0A=E2=80=9CAs a simple example, consider a large service p= rovider=0Anetwork that is extended=0Aprimarily using L2 bridges instead of = L3 routers. The=0Anetwork is therefore seen as=0Aa single link by the IP la= yer. In that case, a new=0Aspoofing attack vector is open to=0Amalicious no= des on the link that could send=0Apackets with spoofed IP source=0Aaddresse= s with low probability of detection,=0Ae.g., to initiate a DoS attack direc= ted=0Ato some other node on the link. AERO=0Atherefore applies to links on = which attached=0Anodes do not necessarily trust=0Aeach other.=E2=80=9D=0A= =0A>Minor issues:=0A>=0A>Section 4.4.5:=0A>The text says to use experimenta= l type code "100" but the ASCII art=0A>still says "137."=C2=A0 Does the fig= ure need to be changed?=0A=0AYes; the figure is incorrect, and will be corr= ected to say "100".=0A=0A>Section 4.4.12:=0A>=C2=A0=C2=A0=C2=A0Eventually, = any such correspondent AERO nodes will receive a NULL=0A>=C2=A0=C2=A0=C2=A0= AERO Redirect message and will cease to use the egress node ('D') as=0A>=C2= =A0=C2=A0=C2=A0a next hop.=C2=A0 They will then revert to sending packets d= estined to the=0A>=C2=A0=C2=A0=C2=A0EUN node ('E') via a trusted intermedia= te router and may subsequently=0A>=C2=A0=C2=A0=C2=A0receive new AERO Redire= ct messages to discover that the EUN node ('E'=0A>=C2=A0=C2=A0=C2=A0) is no= w associated with a new AERO edge router.=0A>Seems like this scenario requi= res that *part* of a prefix that was delegated=0A>to D is now re-routed by = the intermediate router A to a different destination.=0A>Is that correct?= =C2=A0 You are proposing to punch a hole in the original allocation,=0A>and= put in a more-specific (perhaps host-specific) route to E through a new=0A= >path?=C2=A0 What kind of protocols would be used to establish this new for= warding=0A>state?=0A=0APunching a hole in a short aggregated prefix is one= =0Apossibility, but another=0Apossibility is that the edge router is delega= ted many=0Anon-aggregated long=0Aprefixes. In that case, the mobile node ca= n take its long=0Aprefix to a new=0Aedge router without the old edge router= needing to punch any=0Aholes.=0A=0A>Nits/editorial comments:=0A>=0A>Sectio= n 4.4.4:=0A>=C2=A0=C2=A0=C2=A0Note that on links in which link-layer addres= s spoofing is possible,=0A>=C2=A0=C2=A0=C2=A0AERO nodes may be obliged to r= equire the use of digital signatures.=0A>=C2=A0=C2=A0=C2=A0In that case, on= ly the third of the above conditions can be accepted=0A>=C2=A0=C2=A0=C2=A0i= n order to ensure adequate data origin authentication.=0A>Did you mean to s= ay "only the fourth of the above conditions can be=0A>accepted..."? =0A=0A= =0AYou are correct; this was also mentioned in an earlier comment and=0Awil= l be fixed in the next document version.=0A=0A=0A>Section 5:=0A>You say the= re are no IANA considerations, but do you need an experimental=0A>ICMPv6 ty= pe code allocated?=0A=0ANo new experimental ICMPv6 code type needs to be=0A= allocated, since RFC4443=0Asets aside the value =E2=80=9C100=E2=80=9D as an= experimental ICMPv6=0Acode point.=0A> ---2012143828-282926690-1335279507=:26159 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello Pete= ,

Thank you for your com= ments, and please see below for proposed resolutions:

=
Fred
fltemplin@acm.org

>__= ______________________________
> From: Pete McCann <mccap@petoni.o= rg>
>To: gen-art@ietf.org; draft-templin-aero.all@tools.ietf.org <= br>>Sent: Monday, April 23, 2012 9:42 PM
>Subject: Gen-ART Telecha= t 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
>< 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.<= br>>
>Document: draft-templin-aero-10
>Reviewer: Peter McCan= n
>Review Date: 2012-04-23
>IETF LC End Date:
>IESG Telec= hat date: 2012-04-26
>
>Summary: Discuss
>
>Major i= ssues:
>
>Section 4.1 attempts to provide some motivation for t= his draft:
>   In many AERO link use case scenarios (e= .g., small enterprise
>   networks, small and stable M= ANETs, etc.), routers can engage in a
>   classical dy= namic 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 sc= enarios (e.g.,
>   large enterprise/ISP networks, cell= ular service provider networks,
>   dynamic MANETs, etc.), this might be impractical due to routing
>  = ; protocol control message scaling issues.
>However, it isn't cl= ear to me that the mechanisms proposed in this draft
>would be any mo= re scalable than existing dynamic routing protocols.

=0A=0A
Scaling prope= rties of the mechanism are proportional to=0Athe number of distinct
(ingress, egress) pairs of active communication= s.=0AIntuitively, the mechanism will
pro= vide better scaling properties than=0Atraditional dynamic routing protocols= if
the number of active pairs is sparse= =0Ain relation to the number of nodes on the
link. Quantitative analysis would be=0Athrough experimentation after p= ublication.
=0A=0A

>In general, the draft appears to be mix= ing the concepts of service provider
>and end-user networks in strang= e ways.  The AERO link uses host-based
>mechanisms for prefix de= legation, 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 rout= ers on the AERO link are expected to work together in a peer-to-
>pee= r fashion to compute direct routes to each other.  I do not feel that = the
>draft has adequately motivated this somewhat quirky set of assum= ptions.
>Perhaps a deployment example that motivates why the differen= t edge
>routers cannot trust each other is in order.

=0A=0A
A deployment example cou= ld be added as a new Section=0A4.4 (causing existing
Sections 4.4 onward to be renumbered beginning with=0ASection = 4.5). The new
Section could read:
= =0A=0A
 
=0A=0A
=E2=80=9CAs a simple example, consider a large service provider=0A= network that is extended
primarily using= L2 bridges instead of L3 routers. The=0Anetwork is therefore seen as
=
a single link by the IP layer. In that case, = a new=0Aspoofing attack vector is open to
malicious nodes on the link that could send=0Apackets with spoofed IP sou= rce
addresses with low probability of de= tection,=0Ae.g., to initiate a DoS attack directed
to some other node on the link. AERO=0Atherefore applies to link= s on which attached
nodes do not necessa= rily trust=0Aeach other.=E2=80=9D
=0A=0A

>Minor issues:
= >
>Section 4.4.5:
>The text says to use experimental type co= de "100" but the ASCII art
>still says "137."  Does the figure n= eed to be changed?

<= span style=3D"font-size: 11pt; line-height: 115%; font-family: "Calibr= i","sans-serif";">
Yes; the figure is incorrect, and will be corrected to say "10= 0".

>Section 4.4.12:
>   Eventually, any suc= h correspondent AERO nodes will receive a NULL
>   AER= O Redirect message and will cease to use the egress node ('D') as
>&n= bsp;  a next hop.  They will then revert to sending packets = destined to the
>   EUN node ('E') via a trusted inter= mediate router and may subsequently
>   receive new AE= RO Redirect messages to discover that the EUN node ('E'
>  =  ) is now associated with a new AERO edge router.
>Seems like th= is 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.<= br>>Is that correct?  You are proposing to punch a hole in the original allocation,
>and put in a more-specific (perhap= s host-specific) route to E through a new
>path?  What kind of p= rotocols would be used to establish this new forwarding
>state?
=

=0A=0A
Punching a hole in a sho= rt aggregated prefix is one=0Apossibility, but another
possibility is that the edge router is delegated many=0Anon-= aggregated long
prefixes. In that case, = the mobile node can take its long=0Aprefix to a new
edge router without the old edge router needing to punch any=0A= holes.
=0A=0A

>Nits/editorial comments:
>
>Sect= ion 4.4.4:
>   Note that on links in which link-layer = address spoofing is possible,
>   AERO nodes may be ob= liged to require the use of digital signatures.
>   In= that case, only the third of the above conditions can be accepted
>&= nbsp;  in order to ensure adequate data origin authentication.>Did you mean to say "only the fourth of the above conditions can be>accepted..."?

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

>Section 5:
>You = say there are no IANA considerations, but do you need an experimental
&g= t;ICMPv6 type code allocated?

=0A=0A
No new experimental ICMPv6 code type needs to be=0Aal= located, since RFC4443
=0A=0A
sets aside the value =E2=80=9C100=E2= =80=9D as an experimental ICMPv6=0Acode point.
>
---2012143828-282926690-1335279507=:26159--