Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:to...@isi.edu] > Sent: Tuesday, December 06, 2016 12:59 PM > To: Templin, Fred L <fred.l.temp...@boeing.com>; Lucy yong > <lucy.y...@huawei.com>; Brian E Carpenter > <brian.e.carpen...@gmail.com>; int-area@ietf.org > Subject: Re: [Int-area] Some thoughts on > draft-yong-intarea-inter-sites-over-tunnels > > > > On 12/6/2016 12:45 PM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:to...@isi.edu] > >> Sent: Tuesday, December 06, 2016 11:36 AM > >> To: Templin, Fred L <fred.l.temp...@boeing.com>; Lucy yong > >> <lucy.y...@huawei.com>; Brian E Carpenter > >> <brian.e.carpen...@gmail.com>; int-area@ietf.org > >> Subject: Re: [Int-area] Some thoughts on > >> draft-yong-intarea-inter-sites-over-tunnels > >> > >> > >> > >> On 12/6/2016 11:31 AM, Templin, Fred L wrote: > >>> Hi Joe, > >>> > >>>> -----Original Message----- > >>>> From: Joe Touch [mailto:to...@isi.edu] > >>>> Sent: Tuesday, December 06, 2016 11:11 AM > >>>> To: Templin, Fred L <fred.l.temp...@boeing.com>; Lucy yong > >>>> <lucy.y...@huawei.com>; Brian E Carpenter > >>>> <brian.e.carpen...@gmail.com>; int-area@ietf.org > >>>> Subject: Re: [Int-area] Some thoughts on > >>>> draft-yong-intarea-inter-sites-over-tunnels > >>>> > >>>> Fred, > >>>> > >>>> First, we are violently agreeing that subnet redirect works only where > >>>> source addresses cannot be spoofed. The problem is that this is not the > >>>> typical case, so it's not a generic solution IMO. > >>> The same can be said about ordinary host-based Redirect (only works where > >>> the source address cannot be spoofed). The only difference is the attack > >>> surface is larger for subnet redirection which is why RFC6706 does the > >>> due diligence of supporting data origin authentication. > >> Because the attack surface is larger is the reason it's an issue. > > It's not an "issue" because a mitigation is provided. The mitigation is > > needed > > only on links that may be subject to insider attacks - the same can be said > > about standard host Redirects. > > A standard host Redirect affects only one host. This affects the entire > subnet and needs better protection - which isn't always available.
That is what I said - several times. And, that is why RFC6706 specifies mitigations for links where insider attacks may be a concern. For other links, it could be that no mitigations are necessary. The due diligence of RFC6706 is a matter that I think should be appreciated and not scorned. > >>> AERO uses the NBMA tunnel virtual link model meaning that IPv6 ND works > >>> the same as for an NBMA physical link. The model supports traffic > >>> engineering, > >>> multi-homing, route optimization, fault tolerance, mobility management and > >>> security. Do you have a solution for these that does not require new code? > >> I already mentioned it - existing IP forwarding with virtual L2 > >> interfaces. The existing IP forwarding supports TE, multihoming, route > >> optimization, etc - all without any new code. > > I am talking about traffic engineering in terms of selecting one or more > > underlying > > interfaces in the both the outbond and inbound directions. > Sure - the problem is that you have two different TEs running: > > - the main IP forwarding TE that picks the interface The main IP forwarding code will always pick the (singular) areo0 interface. > - the intra-interface forwarding that picks the L2 encaps Yes. > That means the main TE is basically blind to the TE over the subnet. So what? > If you do this with separate L2 VIFs, the main TE can pick the VIF itself. The interface does the right thing. > Everything you want can be done by the main IP forwarding engine - > including ECMP. You didn't address the point about mobility, nor the other points I raised. Are you aware of a mobility solution that requires no supporting code? Thanks - Fred fred.l.temp...@boeing.com > Joe > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area