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: Thursday, December 01, 2016 8:33 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/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?

There needs to be a trust basis for the Redirect target to know that it can
accepted packets from the source's claimed IP addresses. In AERO, the
trust basis is the AERO link critical infrastructure elements including
Servers and Relays. Other link types would need to evaluate what sort
of trust basis is necessary for that particular link.

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

IP-over-Ethernet and other IP-over-(foo) docs don't talk about that, as far as I know.

> >>> >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 don't know about utility outside of AERO. All I know is that there is
significant utility within AERO.

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

IPv6 ND (RFC4861) was developed in an intarea wg (6man). It says that
IP-over-(foo) documents need to be written to tell how to adapt IPv6
ND to specific link types. AERO is an IP-over-(foo) document in exactly
the spirit called for by RFC4861, and by that virtue it would seem to be
aligned with intarea unless there were some consensus to form an
AERO working group. But, I don't see a need to form a new wg just to
get one doc published that just as easily could come out of
intarea itself.

Thanks - Fred
[e-mail]

> Joe
>