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

[Joe Touch <[e-mail]>]

On 12/6/2016 10:19 AM, Templin, Fred L wrote:
> Hi Joe,
>
>> ...
>>>> 6706 is within the context of authenticated origin.
>>> Yes, that is correct. And, RFC6706 applies to all link types that support
>>> Redirection (i.e., and not just tunnel NBMA links).
>> It requires AERO tunneling, though - it doesn't apply to other sorts of
>> IPv6 links, tunneled or not.
> No it doesn't require AERO tunneling - as is said many times over in RFC6706,
> it can be applied to any link type which can use the ordinary Redirect function
> and can provide sufficient trust basis. Ethernet is an example link type where
> RFC6706 can be applied.
We're going in circles. AERO provides the authenticated origin. Most
other IPv6 environments do not. So this isn't a generic mechanism. It
applies only where authenticated origin info is available.

>
>>>> It's a problem in the more general case where that's not known - e.g.,
>>>> where host redirect is already used.
>>> I don't understand the point you are trying to make here, but it
>>> might not even matter.
>> 6706 proposes to use the redirect where source authentication is
>> available - notably within AERO. When that's not available (which is the
>> typical case for most IPv6 fabrics), subnet redirect becomes an
>> efficient attack vector.
> RFC6706 expects a trusted intermediate router so that Redirects cannot
> be spoofed. But again, that trust basis can be established on any link
> type (e.g., Ethernet) and not just tunnels.
Agreed - CAN be  but typically is not.

> ...
>>> RFC6706 specifies subnet redirect for any link type that can support
>>> ordinary Redirect. RFC6706(bis) updates that spec.
>> See above; if it does so on links that don't use AERO tunnels (and thus
>> source authentication), then it's a big security hazard.
> Not true. On a campus Ethernet, if the source and destination can both
> trust an intermediate router then there is a trust basis for the exchange
> of Predirect/Redirect messages. The attack vector is spoofed Predirect
> and Redirect messages, but the trusted intermediate router eliminates
> the attack vector. Again, RFC6706 can be used on any link type.
That supports trusted sources of such messages. On a campus ethernet,
that would require per-packet source authentication which is expensive.
...
>> IP forwarding is supposed to pick outgoing interface and next-hop *IP*.
>> The neighbor cache is supposed to map next-hop IP to L2, but if it does
>> just that it has no way to differentiate packets (e.g., based on QOS).
> In linux at least, there is a "Route to Interface" capability. For example,
> "send all packets with destination covered by 2001:db8::/32 to interface
> aero0". The interface then gets to decide what to do with them, and
> exactly as you say the neighbor cache maps the next-hop IP to L2.
Yes, on Linux there is code that implements a workaround to the fact
that you could - and IMO should - have used separate virtual interfaces.

>
>> The only solution using this (ISATAP) model is to have another instance
>> of IP QOS forwarding happen inside the interface too, so different QOS
>> can have different mappings.
> QoS-base traffic engineering  is accommodated within the AERO interface.
> Also mobility management, security, etc. It works, and I have the code to
> prove it.

I'm not debating whether you CAN solve it this way, but whether you
SHOULD (and whether you even need to).

>> That's why I think this model is incorrect. The simpler approach
>> considers each L2 encapsulation as a separate (virtual) interface to the
>> IP forwarding. In that case, the (one) IP forwarding can pick different
>> outgoing interfaces (with different or similar next-hop IPs), which
>> result in different encapsulations.
> AERO works, Joe. Just because it doesn't look like X-Bone does not
> make it flawed.
The X-Bone works too, and didn't need any of that specialized code
above. That's why I consider the AERO approach to be flawed - it
requires IP routing at a layer that is below IP. That cannot be
correctly integrated with all the other things happening at the main IP
forwarding layer in AERO - but can (and was) in the X-Bone.


>
>>>
>>> All tunnel drivers have code that operates at the sub-IP layer, i.e., and not
>>> just OpenVPN. Look at the linux kernel sit.c, ipip.c, ip_gre.c, etc. drivers, and
>>> look at any apps that use the TUN/TAP interface. This code is not flawed.
>> They should not have IP forwarding mechanisms in that code.
> They can do anything they want inside the interface. Pick the packet up,
> twirl it around, bounce it off the wall, etc. etc. As long as it eventually
> gets encapsulated and shipped off to the correct L2.
They CAN, but IMO they should not. Doing IP forwarding inside an
interface has the potential to interfere (or at least not be integrated
with) primary IP forwarding (that picked that interface).

...

> Joe, I am sorry if the AERO model offends you - perhaps because it differs
> from X-Bone. But, that does not make it wrong. Besides, aren't there any
> number of other existing and emerging tunnel types (e.g., LISP) that don't
> look exactly like X-Bone? 
There's a long list. One of the earliest was the fact that IPsec tunnel
mode buried IP forwarding inside as well - which is why we wrote
RFC3884. Another is the need for two layers of encapsulation to do
tunnels completely. That model is bourne out of a set of capabilities
that none of the current systems - AERO, LISP, etc. - support, all of
which the X-Bone supported nearly 20 years ago - without needing any of
the related "hacks" of replicating IP forwarding anywhere new.

I think AERO adds a few useful things - a better frag/reassembly
mechanism and security - to conventional IP-in-IP or even most other
IP-in-X-in-IP tunnels, but I do not consider it a complete network model.

But we can have the rest of that discussion off--list. We're fall afield
of the origin of this thread.

Joe