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

[Joe Touch <[e-mail]>]

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.


>
>>> 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 intra-interface forwarding that picks the L2 encaps

That means the main TE is basically blind to the TE over the subnet.

If you do this with separate L2 VIFs, the main TE can pick the VIF itself.

Everything you want can be done by the main IP forwarding engine -
including ECMP.

Joe