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: Monday, December 05, 2016 2:47 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/5/2016 2:29 PM, Templin, Fred L wrote:
> > Hi Joe,
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]]
> >> Sent: Monday, December 05, 2016 1:25 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
> >>
> >> Hi, Fred,
> >>
> >>
> >> On 12/1/2016 12:52 PM, Templin, Fred L wrote:
> >>> Hi Joe,
> >>> ...
> >>> Can you say why you think redirecting an entire subnet is potentially more
> >>> problematic (noting that RFC6706 has been published since 2012 and so the
> >>> notion of subnet redirection is already well known)?
> >> 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.

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

> >>>> Yes, buried in 6706 are the issues that might be in such a rev, but we
> >>>> can't expect IPv6 ND implementers to dive into a large spec that has no
> >>>> clear relation to IPv6 and doesn't update 4861 to find it. If there is a
> >>>> way for this approach to be generally useful, it really needs to be in a
> >>>> 4861bis update.
> >>> Not an RFC4861bis, no, but possibly in a document that updates RFC4861.
> >>> Is that what you meant
> >> I was thinking of a single doc focused on the subnet redirect. That
> >> could be in a 4861bis or a single doc that updates 4861, but should not
> >> be a small part of a much larger doc that does many other things
> >> concurrently IMO.
> > 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.

> >>>>>> It acts exactly like one NMBA link on which your endpoint has multiple
> >>>>>> virtual interfaces.
> >>>>> This is from RFC4861:
> >>>>>
> >>>>>      Inbound load balancing - Nodes with replicated interfaces may want
> >>>>>            to load balance the reception of incoming packets across
> >>>>>            multiple network interfaces on the same link.  Such nodes
> >>>>>            have multiple link-layer addresses assigned to the same
> >>>>>            interface.  For example, a single network driver could
> >>>>>            represent multiple network interface cards as a single
> >>>>>            logical interface having multiple link-layer addresses.
> >>>>>
> >>>>> AERO is not talking about inbound load balancing, but it is talking about
> >>>>> a single logical interface having multiple link-layer addresses in exactly
> >>>>> the same spirit as implied by this text.
> >>>> Which is what I said - one link with multiple interfaces. The example
> >>>> given explains that this can be done through interface virtualization,
> >>>> which I also noted.
> >>> No, it agrees with what I said: "a single network driver could represent
> >>> multiple network interface cards as a single logical interface having multiple
> >>> link-layer addresses". One interface; multiple link-layer addresses; one link.
> >> The only difference is whether you can use vanilla IP forwarding (to
> >> pick the outgoing virtual interface) or need some sort of additional
> >> mechanism (that allows multiple IP forwarding entries to use the same
> >> interface and next-hop IP, but needs additional fields to differentiate
> >> the L2 source/dest). With virtual interfaces, you can use existing code.
> > To be completely clear, with AERO the tunnel interface itself (i.e., the
> > AERO interface) is the virtual interface. Within the AERO interface there
> > are one or more underlying interfaces (physical or virtual), with each
> > interface having one or more addresses. The underlying interface
> > addresses are seen as link-layer addresses of the AERO interface.
> >
> > The AERO interface is the node's point of connection to the AERO link,
> > where the AERO link is the entire underlying network. The AERO
> > interface therefore has multiple link-layer addresses but it connects
> > to a single link. This is consistent with the link model for ISATAP which
> > was published as RFC4214/RFC5214.
> >
> > With this model, the inner IP layer uses vanilla IP forwarding to pick
> > the (singular) AERO interface as the outgoing interface. Once inside
> > the AERO interface, the inner IP destination address is mapped to
> > the correct corresponding AERO interface neighbor cache entry,
> > then encapsulation is applied, and then the encapsulated packet
> > is shipped out the correct underlying interface.
> 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.

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

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

> >>>> Whether you use them for input or output reasons is up to the forwarding
> >>>> plane; it shouldn't be buried inside the tunnel mechanism. That's a flaw
> >>>> of many other tunnel approaches.
> >>> I disagree with any implications of a flaw. There is one forwarding table entry,
> >>> but the neighbor cache entry has multiple link-layer addresses. So, IP forwarding
> >>> does its normal thing at the IP layer, but inside the interface the packet is
> >>> forwarded to the correct link-layer address of the neighbor among multiple
> >>> candidates at the sub-IP layer. I can demonstrate this in running code today.
> >> I agree this works, but you need your new code to accomplish this for
> >> the very reason you cite.
> > 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.

> >> If you treat these as different interfaces, then existing forwarding
> >> code would have sufficed.
> > Existing IP forwarding code does suffice with a single interface. It is the
> > same as on any multipoint interface (e.g., Ethernet).
> Multipoint interfaces don't generally allow different encapsulations for
> the same destination IP address.
> (I claim that those that do aren't multipoint interfaces; they're hack
> implementations of multiple interfaces as if they were one).
> 
> ...
> >
> >>>>>  But, by allowing multiple S/TLLAOs
> >>>>> on IPv6 ND messages, AERO nodes can tell their neighbors about their
> >>>>> multiple link-layer address and how they prefer to have those link-layer
> >>>>> addresses used for inbound traffic.
> >>>> In my terminology, they affect the forwarding table. Sure.
> >>> They do not affect the forwarding table at the IP layer.
> >> They should. You're effectively using a different link source/dest.
> > I'm not sure if this statement is born from a misunderstanding of the
> >  AERO interface/link model or some kind of preconceived notions you
> > may have from some other context. But, it is one (virtual) interface
> > connected to one (virtual) link the same way as Ethernet has one
> > (physical) interface connected to one (physical) link.
> An ethernet interface has one "dest IP" -> "dest L2" map entry.
> When you have multiple dest L2s for the same dest IP, you are doing IP
> routing (IMO incorrectly) inside the link layer.
>
> >>> The IP layer sees only
> >>> a single next-hop while the sub-IP layer gets to see the multiple link-layer
> >>> addresses in the neighbor cache entry.
> >> That's the flaw, IMO - it's not needed of you use VIFs (we demonstrated
> >> this in the X-Bone).
> > Not adhering to the X-Bone model does not necessarily constitute a flaw.
> Of course, but you should consider that the tunnel doc that has taken
> years to converge is largely based on the X-Bone's model.

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? 

Thanks - Fred
[e-mail]

> Joe