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

[Joe Touch <[e-mail]>]

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.

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


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



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

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.

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.

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

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