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

[Joe Touch <[e-mail]>]

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.

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 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

>
>> 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.

>
>> 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).

Joe