Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Tuesday, December 06, 2016 1:28 PM > To: Templin, Fred L <[email protected]>; Lucy yong > <[email protected]>; Brian E Carpenter > <[email protected]>; [email protected] > Subject: Re: [Int-area] Some thoughts on > draft-yong-intarea-inter-sites-over-tunnels > > Fred, > > ... > >> 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. > > I never scorned it; I just said that it's not complete.
RFC6706 has thoroughly discussed the threat model and provides effective mitigations. It is therefore complete. > If this is to be a generally useful mechanism, it needs to come out of > the AERO spec and be described as a direct extension to IPv6 ND > redirects, but that requires a much more detailed discussion of the > security requirements and how they can be achieved in existing IPv6 > deployments. > > >>>>> 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. > If there are multiple interfaces, why would it pick aero0? And what > would its QoS be? It can't have a single value, so the main IP > forwarding code can't decide between aero0 and other interfaces. The IP forwarding table has an entry such as: 2001:db8::/32 -> aero0 Meaning that any IPv6 packet with a destination that matches 2001:db8::/32 *and for which no more-specific route exists* goes out interface aero0 unconditionally. The packet will have a TOS value, and it is that TOS that guides the aero0 interface on how to portion traffic over the underlying interfaces. > >> - 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? > That means you potentially have two TEs fighting each other. I There is no fight if the IP layer has only one outbound interface alternative. > >> If you do this with separate L2 VIFs, the main TE can pick the VIF itself. > > The interface does the right thing. > The interface can only do the right thing with the traffic it has > already been given by the main IP forwarder. It can't collaborate with > that forwarder. No, the AERO interface doesn't need to collaborate with the IP layer. All it does is looks at the packet's TOS value and uses that to select one or more outbound underlying interfaces. > >> 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? > The other cases are either handled by existing IP forwarding or require > exactly the same amount of mechanism inside the IP forwarder that you > implement in the interface instead (e.g., for mobility and dogleg > redirection). AERO mobility management and route optimization are better than existing approaches. That is why the aviation and corporate mobile device communities are looking at it. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
