Subject: Review for draft-smith-6man-link-locals-off-link-00.txt

From: "Liushucheng (Will)" <[email-masked]>
Date: Wed, 16 Sep 2015 11:45:15 +0000

Hi Mark and all,

I read this draft and my comments listed below.

Section 2:
>    This memo uses the more general term "Constrained Broadcast Multi-
>    Access" (CBMA) to describe these types of links.  These types of
>    links are distinct from Non-Broadcast Multi-Access (NBMA) links.

It might be a good idea to provide a brief comparison of CBMA and NBMA.

Section 4:
>    This limited Link-Local reachability can be detrimental to the
>    operation of IPv6 applications, as IPv6 applications are permitted to
>    use Link-Local addresses for their connectivity [RFC4007], and if
>    multiple scopes of addresses are available for the application to
>    use, Link-Local addresses will be preferred over all others with
>    exception to the loopback address, due to the general rule of
>    preferring addresses with the smaller scopes [RFC6724].

IMHO, the problem here is that you should only use a link-local destination address if you know that such address belongs to one of your zones.

Section 5.1:
> 
>    To signal to hosts that they should consider Link-Local destinations
>    "off-link", a router sends a Link-Local Prefix Information Option in
>    its Router Advertisements [RFC4861], with the following PIO field
>    values:

How is ND supposed to operate if link-local addresses are off-link? It might be a good idea to clarify this in a subsequent discussion paragraph.

Section 8 (Security Considerations):
>    Allowing Link-Local source and destination addresses to be used in an
>    IPv6 over CBMA network does not reduce this security benefit.

Limiting the use of link-local addresses within their own zone scopes respectively provides implicit network isolation, which results in a sort of security benefit. Therefore, I don't think breaking such limits will not affect the security benefit.

Regards,
Will 

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Mark Smith
> Sent: Sunday, August 16, 2015 8:39 PM
> To: 6man WG
> Subject: Fwd: New Version Notification for
> draft-smith-6man-link-locals-off-link-00.txt
> 
> Hi,
> 
> I've had this idea for a while, finally got around to writing it up.
> 
> The idea is override the Link-Local on-link default assumption so that Link-Local
> addresses can be used on "Constrained Broadcast Multi-Access Links" e.g.,
> TR-101 N:1 VLANs or "Private VLANs".
> 
> Regards,
> Mark.
> 
> ---------- Forwarded message ----------
> From:  <[email-masked]>
> Date: 16 August 2015 at 22:35
> Subject: New Version Notification for
> draft-smith-6man-link-locals-off-link-00.txt
> To: Mark Smith <[email-masked]>
> 
> 
> 
> A new version of I-D, draft-smith-6man-link-locals-off-link-00.txt
> has been successfully submitted by Mark Smith and posted to the IETF
> repository.
> 
> Name:           draft-smith-6man-link-locals-off-link
> Revision:       00
> Title:          Indicating Link-Local Unicast Destinations are Off-Link
> Document date:  2015-08-16
> Group:          Individual Submission
> Pages:          10
> URL:
> https://www.ietf.org/internet-drafts/draft-smith-6man-link-locals-off-link-00.tx
> t
> Status:
> https://datatracker.ietf.org/doc/draft-smith-6man-link-locals-off-link/
> Htmlized:
> https://tools.ietf.org/html/draft-smith-6man-link-locals-off-link-00
> 
> 
> Abstract:
>    Certain link-layers limit reachability for one set of nodes, while
>    permitting full reachability for a different set of nodes, for
>    unicast, multicast and broadcast traffic.  If IPv6 hosts are members
>    of the first set of nodes, and IPv6 routers are members of the
>    second, Link-Local traffic between IPv6 hosts will fail, due to the
>    default on-link assumption for Link-Local destinations.  This memo
>    describes the use of a Link-Local Prefix Information Option to
>    indicate to these hosts that Link-Local destinations are "off-link",
>    and are reachable via their default router(s).
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Tue, 22 Sep 2015 18:03:51 +1000

Hi Will,

> I read this draft and my comments listed below.

Thanks very much for your time and comments.

> It might be a good idea to provide a brief comparison of CBMA and NBMA.

OK.

> IMHO, the problem here is that you should only use a link-local destination address if you know that such address belongs to one of your zones.

So the unstated assumption was that an application, if it has a
link-local address that it could use as a destination address, also
knows the correct zone for the link-local address. It would have
learnt the link-local destination address and correct zone via
something like manual configuration or Multicast DNS.

The problem the draft is trying to resolve is that when an application
has the correct link-local destination address and zone information,
it can successfully use the LL address on traditional broadcast
multi-access links, P2P links and NBMA links, but can't on CBMA links.
I think the trouble is there is no granularity to this link-local
isolation - it is absolute, and cannot currently be overridden. There
is currently no way to permit some link-local traffic between CBMA
attached hosts while prohibiting other link-local traffic between
hosts. It is permit all link-local traffic between hosts (by not using
a CBMA type link) or permit no link-local traffic between hosts (by
using a CBMA type link).

> How is ND supposed to operate if link-local addresses are off-link? It might be a good idea to clarify this in a subsequent discussion paragraph.

I don't mind clarifying it, however ND would work the same as if ULA
or GUA addresses were designated off-link (by not switching on the
L-bit in their respective RA PIOs) i.e., send everything to the(/a)
default router, meaning that the only thing ND needs to resolve is
the(/a) default router's address, if it isn't already resolved by
receiving an RA with a Source link-layer address option.

> Limiting the use of link-local addresses within their own zone scopes respectively provides implicit network isolation,

So I think the security goal behind using CBMA type links is to either
completely isolate hosts from each other, or insert a device between
the hosts that can perform security inspection of the traffic before
forwarding it onto destination hosts attached to the same link (and
different links).

My definition of 'host isolation' is binary - if host A is isolated
from host B, then host A cannot reach host B regardless of what
addresses Host A uses to reach host B.

In the CBMA scenario I'm describing, assuming there are ULA and/or GUA
prefixes associated with the link, via RA PIOs without their L bits
switched on, Host A is not isolated from host B, because host A can
still reach host B using its ULA or GUA addresses. Only Link-Locals
fail in this scenario due to the default on-link assumption of
Link-Locals.

So the 'isolation' is limited to only to when Host A attempts to use
link-local addresses to reach Host B. There is certainly security
value in that limited isolation, however it also prevents applications
being able to use link-local addresses when they might benefit from
doing so, and unless the application uses Happy Eyeball's techniques
to attempt to connect to all possible addresses that its link-layer
neighbor may have, connection attempts will either completely fail, or
will have to timeout before attempts are made to use Host B's ULA or
GUA addresses instead (which will succeed).

Fundamentally, I'm trying to make the Link-Local isolation in a CBMA
network more granular, so that Link-Locals can be used by applications
if the traffic successfully passes any security policies that are
implemented on the router(s)/firewall(s) that would be used to reach
other hosts attached to the CBMA link. The current situation of all
Link-Local traffic failing is still achieved if desired by dropping
all inter-host Link-Local traffic.

Regards,
Mark.

> which results in a sort of security benefit. Therefore, I don't think breaking such limits will not affect the security benefit.
>
> Regards,
> Will
>