Subject: Re: I-D Action: draft-smith-6man-link-locals-off-link-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Aug 2015 14:20:22 +1200

I have a question.

How did the host that is attempting to send a packet to its
unreachable neighbour learn the address of that neighbour
in the first place? As far as I can see, neighbour discovery is
clearly going to fail anyway, since neither Neighbor Solicitation
nor Neighbor Advertisement will be delivered.

So which idiot told the host the target's link-local address?

Regards
   Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 19 Aug 2015 07:16:28 +0200 (CEST)

> So which idiot told the host the target's link-local address?

I guess it could be for instance the router proxying mDNS packets between 
the multicast/broadcast domains?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: David Farmer <[email-masked]>
Date: Wed, 19 Aug 2015 01:53:27 -0500

> On Aug 18, 2015, at 21:20, Brian E Carpenter <[email-masked]> wrote:
> 
> I have a question.
> 

Well having the router forward multicasts received from other hosts is discussed in the last paragraph of section 3.  But point taken, if you simply don't do that and implement a ND proxy on the router, then there wouldn't be any link-local traffic not already addressed to router.  But that would be equivalent to NBMA or full isolation, I think the intention is better described as semipermeable rather than full isolation.

The draft talks about security as a reason to implement this model, but that implies full isolation to some people.  I had been thinking about using it to significantly reduce broadcast/multicast traffic on WiFi.  Without completely eliminating multicast.  Maybe this kind of use case should be discussed in a little more detail in the draft, making clear full isolation isn't necessarily the intention.

But this is still in my, it maybe crazy idea bucket.  :)

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: Mark Smith <[email-masked]>
Date: Wed, 19 Aug 2015 17:41:36 +1000

Hi Brian,

> nor Neighbor Advertisement will be delivered.

Right. The failure to resolve the link-local address will cause the
application to fail to connect, unlike on a conventional
(unconstrained) broadcast multi-access, NBMA or point-to-point link
where link-locals work.

Here is what happens today for a host sending to various destinations
attached to the same CBMA link:

GUA destination -> is "offlink": true (GUA PIO L=0) -> send via
default router -> back onto link to GUA destination -> success
ULA destination -> is "offlink": true (ULA PIO L=0) -> send via
default router -> back onto link to ULA destination -> success
LL destination -> is "offlink": never (no PIO, default RFC5942
assumption)-> send directly to link neighbor-> fail because of CBMA
layer 2 constraints

What I'd like to see is the following, so that Link-Local behaviour on
CBMA links matches that on BMA, NBMA and P2P links:

GUA destination -> is "offlink": true (GUA PIO L=0) -> send via
default router -> back onto link to GUA destination -> success
ULA destination -> is "offlink": true (ULA PIO L=0) -> send via
default router -> back onto link to ULA destination -> success
LL destination -> is "offlink": true (LL PIO L=0, override default
RFC5942 assumption)-> send via default router -> back onto link to LL
destination -> success

I don't think this reduces security in any way, the default router
forwarding Link-Local traffic can be doing more than just IPv6
forwarding i.e. packet filtering or stateful firewalling, just as it
would also need to be for ULA or GUA traffic if you want to have more
control over what hosts on the same CBMA link can send to each other.

Regards,
Mark.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Wed, 19 Aug 2015 20:15:16 +1000

Hi David,

> Well having the router forward multicasts received from other hosts is discussed in the last paragraph of section 3.  But point taken, if you simply don't do that and implement a ND proxy on the ro…

True, there is a level of 'leaking' in the sense that multicasts from
routers towards hosts would be seen by all hosts.

The text in the last paragraph about multicasts is just some thoughts
about taking this model even further. In that model hosts can send LL,
ULA, GUA unicasts and multicasts to all other hosts on the link, but
all of that traffic must go through a layer 3 forwarding device,
creating the opportunity to apply layer 3 and greater security
policies to it.

Another way to think of it is that the link is still multi-access, but
rather than supporting full-mesh/peer-to-peer unicast and multicast
reachability between nodes, a (Nx)hub-and-spoke forwarding model
within the link for all traffic is forced, so that the IPv6
routers(/firewalls) at the hub(s) can inspect the traffic before
forwarding it to any or all of the hosts at the spokes.

> The draft talks about security as a reason to implement this model, but that implies full isolation to some people.

So I don't think hosts are "fully isolated" if, while you can't reach
them with Link-locals across the link, you can reach them with ULAs or
GUAs, which is the case today with a CBMA type link, unless the router
that the ULA/GUA traffic goes through applies security policies to the
ULA/GUA traffic.

If people want hosts to be properly isolated from each other, then the
isolated hosts have to be on separate physical or virtual links, with
the associated additional costs of additional subnets, more control
plane state and processing, and more configuration effort. In that
scenario, hosts would/should be trusted enough such that the
constraints a CBMA link imposes shouldn't be necessary and would
probably be annoying i.e., the link would be a conventional BMA link

I think people who would implement a CBMA type link, rather than full
isolation via different links, have achieved their security goal when
hosts can't directly send traffic to each other across the link, and
there is a security policy device that can permit inter-host traffic
on the link if it has passed the policy.

> I had been thinking about using it to significantly reduce broadcast/multicast traffic on WiFi.  Without completely eliminating multicast.  Maybe this kind of use case should be discussed in a little more detail in the draft, making clear full isolation isn't necessarily the intention.
>

Just to be sure I understand, would that reduction in multicast
traffic be because the hosts' multicasts only reach the routers due to
the layer 2 forwarding constraints of the CBMA link, and that the
routers are in a position to choose as to whether or not the
multicasts are forwarded back onto the link (forgetting for the moment
that how this exactly would work isn't quite there yet.)

> But this is still in my, it maybe crazy idea bucket.  :)

I don't think it is that crazy. Once we have a layer 3 router/firewall
between all the hosts on the link and all other on and off-link
destinations, that can have a look at all of the hosts' Link-Local,
ULA/GUA unicast and multicast traffic, there is a lot of flexibility
to do things like limit multicasts between the hosts for power saving
reasons.

Regards,
Mark.

---

From: Dennis Ferguson <[email-masked]>
Date: Wed, 19 Aug 2015 18:16:58 -0700

Hello,

> (unconstrained) broadcast multi-access, NBMA or point-to-point link

I'm confused about how this answers the question, though.  If I write
down the link-local address of a machine attached to my (unconstrained)
broadcast multiaccess network at home, go to work and try to connect
to the same machine using that address, it will fail to connect.  The
reason it will fail to connect is that the host I'm trying to connect
to using that link-local address is off-link, just like most other hosts
on the planet are.  Link-local addresses don't work if the hosts are
off-link, a fact that is entirely unsurprising and is not in need of
fixing, so applications which need to talk to off-link destinations
will need to avoid trying to use link-local addresses to do so.

So I think the question remains: what made the application trying to
connect to an off-link destination using a link-local address think
that this should work?

What is "on-link" and what is "off-link" is neither arbitrarily determined
nor defined by addressing, it is a property of the L2 connectivity that
exists.  Once whatever is necessary for address resolution has been done
a host can expect that a packet sent to an on-link neighbor with a TTL of
255 will arrive with a TTL of 255, that a packet sent with a TTL of 1
will arrive, and that it may be able to continue to talk to an on-link
neighbor even if the routers go away.  An application which doesn't care
about any of this also needn't care what kind of address it uses to talk
to its neighbor and can just pick one that works, but an application which
goes out its way to use a link-local address may very well rely on the
nature of the service it expects to get by limiting itself to on-link
neighbors this way and I think that connection should probably fail if the
expected service can't be delivered.

I think I understand the bigger problem you are trying to solve.  The hosts
and the routers have asymmetric views of what is on-link and what is off-link:
from the point-of-view of a host it is on a link with a router or two but
nothing else, while the routers see themselves as on-link with everything
so behavior somewhere will need to change to deal with the asymmetry.
What I don't get is why you seem to want to change the host behavior to
be more consistent with the router's view of the link, rather than just
limiting the changes to make the router's behavior consistent with the
hosts' view.  Not only is the router the preferred place to deal with
oddities, since there are usually fewer of them than hosts and we already
expect to have to configure them to do stuff in any case, but in this
case the changes in the router will involve making the router behave
(from the hosts' point of view) as if the router has more limited L2
connectivity than it actually does, which can sometimes be done, while
making the host conform to the router's view requires making the hosts
behave is if they have more extensive L2 connectivity than they actually
do, which is impossible.  The L2 connectivity the hosts have is all
they have to work with, so I think you must make the routers behave
consistently with the host view of their link.

To do that I think you would want to make modifications to the router behavior
like the following:

- When the router forwards a packet from one host to another it should
  not send a redirect pointing the source host directly at the destination.
  While doing so might be consistent with the router's view of the link
  it is inconsistent with the host's.

- When the router receives a packet from a host destined to a link-local
  address of another host it should drop the packet.  While this might
  be same-link forwarding from the router's view of the link it is off-link
  forwarding from the point of view of both hosts, so to be consistent
  with the host view it shouldn't be done.

- When the router receives an unrouted multicast from a host it should
  not attempt to deliver that packet to other hosts.  Unrouted
  multicasts don't leave the link they were sent on so doing this would
  be inconsistent with the hosts' view of their links (not to mention
  inconsistent with the router's view as well).

- I think a multicast router is going to have a problem with this link
  if it can't omit the originating host when flooding to the others.
  You'll need to decide if you care or not.

I'm not positive, but I think most what you seem to want to do works (if you
don't need to deal with IPv4) without changes to the hosts if you just let
each host believe it is alone on a link with a router or two, and don't
let the routers do anything inconsistent with that.  Is there a reason
not to do it this way?

Dennis Ferguson

---

From: Mark Smith <[email-masked]>
Date: Thu, 20 Aug 2015 20:02:51 +1000

Hi Dennis,

What I'm really taking about is whether a host can reach a link local
destination attached to the same link instance directly.

The L-bit in a PIO indicates whether the host should try to reach the
destination directly, or to send the packet to a router.

For link-local destinations, hosts are to always co

> will need to avoid trying to use link-local addresses to do so.

So the trouble I've had is that I've had to adopt the "on-link"/"off-link"
terminology, because that is what the "L" bit in a PIO is theoretically
indicating.

In reality, what it is really indicating is whether a host should try to
directly send a packet to the destination covered by the PIO prefix, or to
send it to one it's default routers, either for transmission over another
link, or back onto the same link.

So when I've described enabling hosts to treat Link-Locals as "off-link",
all I'm really saying is that the host should send traffic to all
Link-Local destinations to one of its default routers. Currently, hosts
always try to send to Link-Local destinations directly, and that cannot be
changed.

The "L" bit would be better described as the "send direct to destination"
or "send via router" bit.

> to its neighbor and can just pick one that works,

Actually, if there is a choice, LLs are listed first (preferred) over GUA
and ULA addresses in the return from the getaddrinfo() call, as smaller
scopes are preferred in the IPv6 address selection RFC.

> but an application which

> expected service can't be delivered.

Yes, and that failure will either be made visible to the end-user, even
though the destination is reachable via GUA/ULAs if they exist, or
applications will have to adopt happy-eyeball techniques to hide Link-Local
failures when GUA/ULAs are also available.

> so behavior somewhere will need to change to deal with the asymmetry.

Yes.

If security is the motivation for the CBMA link, there is still a device
that can enforce security policy between hosts even if their applications
choose to use LLs instead of GUAs or ULAs to reach other hosts that are
connected to the same link (but not directly reachable).

> hosts' view.

So the only alternative is for the router to perform ND Proxy for
Link-Local destinations.

So why is it necessary to use ND Proxy for LLs, but not for GUAs and ULAs?
Why wasn't ND proxy used to solve the problem for GUAs and ULAs too? PIOs
could have just been used for SLAAC operation, rather than also making a
statement about whether the GUA or ULA destination is directly reachable
over the link, or reachable indirectly via a default router.

>  Not only is the router the preferred place to deal with

>   it is inconsistent with the host's.

Yes, on a CBMA link, routers' sending redirects has to be switched off.

>   with the host view it shouldn't be done.

I consider that too big a hammer. Applications are permitted to use LLs,
and I think the IPv6 address selection RFC actually effectively courages it
because it prefers LLs over larger scoped addresses like GUAs/ULAs - if
they exist.

>   You'll need to decide if you care or not.

So you're sort of describing all the problems that CBMA links create that
don't exist on BMA, NBMA and point-to-point links. I want to solve these
problems for CBMA links, while still giving people who want the "problems"
for security reasons the option to have them.

Regards,

Mark.

---

From: Dennis Ferguson <[email-masked]>
Date: Fri, 21 Aug 2015 08:09:14 -0700

Mark,

On 20 Aug, 2015, at 03:02 , Mark Smith <[email-masked]> wrote:
> What I'm really taking about is whether a host can reach a link local destination attached to the same link instance directly.

Here's the definition of "link" from RFC2460:

   link        - a communication facility or medium over which nodes can
                 communicate at the link layer, i.e., the layer
                 immediately below IPv6.  Examples are Ethernets (simple
                 or bridged); PPP links; X.25, Frame Relay, or ATM
                 networks; and internet (or higher) layer "tunnels",
                 such as tunnels over IPv4 or IPv6 itself.

Given this I think your statement of the problem is really difficult to parse.
Hosts attached to the same link can communicate directly at the link layer.
Hosts that can't communicate directly at the link layer are not attached to
the same link.  Link local addresses may only be used to communicate with
nodes attached to the same link which, by definition, can be reached directly
at the link layer.

If you restrict the link layer connectivity of a host you have unavoidably
restricted the scope of the link to which it is attached to the neighbors it
can still reach directly at the link layer.   If a host thinks it should be
able to reach a link local destination that it cannot communicate with at
the (restricted) link layer you have a problem, but it is not a problem you
can fix with a router.  You instead need to fix whatever it is that lead the
host to think that would work.

This is why the question of how the host came to know the off-link link local
address is exactly on target; the answer would reveal what needs to be
fixed.  I don't think you have answered this question yet.  If there is no
answer to this there may be no problem to fix.

Dennis Ferguson

---

From: Mark Smith <[email-masked]>
Date: Sat, 22 Aug 2015 10:03:42 +1000

Hi Dennis,

On 22 August 2015 at 01:09, Dennis Ferguson <[email-masked]> wrote:
> the same link.
>  Link local addresses may only be used to communicate with

Here's a definition from RFC4861 that describes the characteristics of
a CBMA-type link from the perspective of IPv6 neighbor reachability.

   shared media   - a link that allows direct communication among a
                    number of nodes, but attached nodes are configured
                    in such a way that they do not have complete prefix
                    information for all on-link destinations.  That is,
                    at the IP level, nodes on the same link may not know
                    that they are neighbors; by default, they
                    communicate through a router.  Examples are large
                    (switched) public data networks such as Switched
                    Multimegabit Data Service (SMDS) and Broadband
                    Integrated Services Digital Network (B-ISDN).  Also
                    known as "large clouds".  See [SH-MEDIA].

Note, "That is, at the IP level, nodes on the same link may not know
that they are neighbors; by default, they communicate through a
router."

This is what allows GUAs and ULAs to work over a CBMA link if the
L-bit is switched off for their PIOs. The trouble is that currently it
isn't possible for Link-Local's to be used over 'shared media' links
with CMBA reachability limitations, because hosts always consider LL
destinations to be "on-link" (per RFC5942).

It seems really inconsistent to me that GUAs and ULAs will work over
these types of links by default (due to the default "off-link"
assumption for those prefixes), where as LLs won't, but more
importantly, LLs can't be made to work even if desired, despite LLs
being a more preferred address type to use vs. GUA/ULAs, as per the
IPv6 address selection rules.

I'm fine with security being a reason to limit this reachability.
However, I think the absoluteness of the LLs not and currently never
working over CBMA type links should be changed, allowing more granular
security to be applied to LL traffic over CBMA links if desired.

Regards,
Mark.