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

[Joe Touch <[e-mail]>]

On 12/1/2016 8:20 AM, Templin, Fred L wrote:
> ,,,
>>> It is the same as the way the Redirect function works on physical links, except
>>> that the Redirect applies to an entire network prefix and not just a singleton
>>> address. This has already been published in RFC6706, and what we are now
>>> specifying is essentially RFC6706(bis).
>> OK, then the bis doc might fall within INTAREA (though I would think it
>> could be very hazardous to allow a redirect to apply to an entire
>> prefix! - isn't that an attack vector?)
> It is secure, because there is a trust anchor (the AERO Server) that is trusted by
> both AERO Clients (the source and target) and the Clients will only accept the
> Redirection if it comes through the Server. The difference is that the source
> Client has to solicit a Redirect by first sending what is called a "Predirect". The
> Predirect lets the target Client know that source is authorized to source packets
> from its claimed prefix, and the target Client returns a Redirect. When the source
> Client gets the predirect, it knows that the target Client is prepared to accept its
> packets via the direct path not including the Server. This basic behavior is already
> discussed in RFC6706, but we are seeking to (bis) that work now.

But is this safe outside of the AERO environment?


>
>
>>> ....
>>> The AERO interface is an NBMA interface where the ingress sees all potential
>>> egresses as potential "neighbors".
>> Isn't that true for all multipoint links?
>>
>>> An AERO interface that is configured over
>>> multiple underlying interfaces would appear to have multiple link-layer
>>> addresses. Each link-layer address can have a different set of TOS-based
>>> priorities so that the AERO interface can specify to its neighbors as to
>>> which link-layer address to use for which class of traffic.
>> That just means you have a tunnel model that allows one instance to
>> represent multiple tunnels (or tunnel interfaces). That's fine, but
>> seems local to the definition of the tunnel.
> No, it is one tunnel interface with potentially multiple link-layer addresses.
...

OK. We already have models for that - ethernet interfaces have multiple
addresses too.
>>> >From an IPv6 neighbor discovery standpoint, this is realized by allowing IPv6 ND
>>> messages to include multiple S/TLLAOs - one for each underlying interface. Each
>>> S/TLLAO has a set of TOS-based priorities allowing neighbors to select the best
>>> underlying interface for the given packet TOS. This is described in Section 3.5
>>> of the document. I can demonstrate how this works in actual running code
>>> over a webex if you would like.
>> I understand the principle, but you're describing a feature of the
>> tunnel mechanism that seems based largely on applying existing IP
>> capability inside the tunnel.
> What I am describing is an augmentation of IPv6 neighbor discovery where ND
> messages can carry multiple S/TLLAOs and the neighbor cache entries can have
> multiple link-layer addresses. RFC4861 is silent on whether this is permissible.
> AERO makes it explicit.

But my question is whether this requires something specific to AERO to
work or has generic utility even in the base Internet.

>
>>>>>> I'm not claiming this wouldn't be useful.  I'm saying that we need to
>>>>>> know what problem it solves to know where to home it.
>>>>> I have identified two very important use cases relating to aviation.
>>>> You've defined a customer, IMO - which is great, but short of taking
>>>> this to an aerospace forum, it doesn't really help me understand where
>>>> in the IETF it should be discussed.
>>> It is being proposed to the International Civil Aviation Organization (ICAO)
>>> where standards are being established for the future civil aviation data
>>> communications architecture.
>> Sure, so it sounds like a standard there and a de-facto one within the
>> IETF (e.g., individual informational).
> ICAO is not a community of network and computing equipment engineers
> and researchers in the same way as the IETF is. There is no one in ICAO
> who can serve as an RFC Editor for a standard that would be based on
> AERO or any other network technology. There is no one in ICAO who
> can build reference implementations and/or establish rough consensus
> among the network and computing equipment community. ICAO looks
> to the IETF for Internetworking standards.
>
>> I haven't seen a case yet as to why INTAREA should adopt it per se...
> Everything we have talked about above relates to a specific link layer model
> for tunnels (NBMA) and is manifested as an "IP-over-(foo)" document much
> in the same spirit as for IP-over-Ethernet, IP-over-FDDI, IP-over-ATM, etc.
> That seems like an Intarea consideration to me.
I looked at a few of those, and they were mostly homed in tech-specific
WGs, not in INTAREA.

Joe