Hi Joe, > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Tuesday, December 06, 2016 11:36 AM > 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 > > > > On 12/6/2016 11:31 AM, Templin, Fred L wrote: > > Hi Joe, > > > >> -----Original Message----- > >> From: Joe Touch [mailto:[email protected]] > >> Sent: Tuesday, December 06, 2016 11:11 AM > >> 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, > >> > >> 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. > > 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. Take for example a hypothetical cellphone that keeps both the 4G and WiFi links active at the same time. TE should be able to steer some messages out the 4G interface and others out the WiFi interface - say, texts over 4G and http over WiFi. In the inbound direction, I am talking about allowing the node to tell the network how to deliver its inbound traffic. It is also possible to have asymmetry where outbound packets going out over interface A and inbound packets coming in over interface B. And then, I am also talking about the possibility of packet replication with duplicate copies sent out one over the WiFi and the other over the 4G. I am talking about multihoming in terms of having the singular tunnel virtual interface configured over multiple underlying physical or virtual interfaces. You can employ traffic engineering over the underlying interfaces as I mentioned above, and you can change over from interface A to interface B if interface A goes down. I am talking about route optimization in terms of eliminating extraneous doglegs from the path so that packets going from A->B->C can travel directly from A->C instead. And, I am talking about mobility and mobile networks in a way that is better than Mobile IP. You didn't mention that in your list perhaps because you know that mobility requires extra code. In AERO, a mobility event is what happens when the IP address of an underlying interface changes. And, the AERO node simply informs its neighbors of the L2 address change by sending IPv6 ND unsolicited Neighbor Advertisements the same as for any link. I am not talking about anything different than IPv6 ND and DHCPv6 messaging over an ordinary IP link because those are the only mechanisms that are used. Thanks - Fred [email protected] > Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
