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 10:39 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 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.

On link types where the L2 source address cannot be spoofed, all it requires
is testing the L2 source address against a list of approved L2 source addresses.
This is needed even on links that support mechanisms like IEEE802.1x, since
otherwise there could be an insider attack. 

This same attack vector could be a matter of concern for even regular
host-based Redirection, by the way. The only reason AERO takes greater
pains to do message origin authentication is that the attack surface is
larger for redirection of an entire subnet than it is for redirection of
a singleton IP address.

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

The point is that the mechanism can be applied generically to any link type.

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

The source authentication is simply checking the L2 source against a list
of known trusted L2 sources. That is not very 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).

But, AERO DOES solve it this way.

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

Has X-Bone carried forward into modern implementations?

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

I think you are concerned for no good reason, Joe. IP forwarding still
works exactly the way it always has while AERO does its thing at the
sub-IP layer.

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

IP forwarding picks the interface in exactly the way it is supposed to,
and the interface does the rest at the sub-IP layer. There is no potential
for interference.

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

Again, Joe, I am sorry if you don't like it but there is nothing lacking or broken.

Thanks - Fred
[e-mail]

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