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 12:59 PM
> 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 12:45 PM, Templin, Fred L wrote:
> > 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.
> 
> 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
[e-mail]

> Joe
>