Re: [Int-area] Some thoughts on draft-yong-intarea-inter-sites-over-tunnels

["Templin, Fred L" <[e-mail]>]

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Tuesday, December 06, 2016 11:36 AM
> To: Templin, Fred L <[e-mail]>; Lucy yong <[e-mail]>; Brian E Carpenter
> <[e-mail]>; [e-mail]
> 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:[e-mail]]
> >> Sent: Tuesday, December 06, 2016 11:11 AM
> >> To: Templin, Fred L <[e-mail]>; Lucy yong <[e-mail]>; Brian E Carpenter
> >> <[e-mail]>; [e-mail]
> >> 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
[e-mail]

> Joe