Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

From: [email-masked]
Date: Wed, 13 Sep 2017 07:04:00 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations WG of the IETF.

        Title           : Unique IPv6 Prefix Per Host
        Authors         : John Jason Brzozowski
                          Gunter Van De Velde
	Filename        : draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
	Pages           : 9
	Date            : 2017-09-13

Abstract:
   This document outlines an approach utilising existing IPv6 protocols
   to allow hosts to be assigned a unique IPv6 prefix (instead of a
   unique IPv6 address from a shared IPv6 prefix).  Benefits of unique
   IPv6 prefix over a unique service provider IPv6 address include
   improved host isolation and enhanced subscriber management on shared
   network segments.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-08

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: james woodyatt <[email-masked]>
Date: Wed, 13 Sep 2017 12:09:19 -0700

>   improved host isolation and enhanced subscriber management on shared

This revision greatly improves on its predecessor, but I’m still left wondering why the word “redirect” doesn’t appear anywhere in the text. Shouldn’t it make an explicit recommendation that routers never send them? And if that’s not the recommendation, then shouldn’t it say something about how to provide improved isolation between connected visitor devices while still admitting the use of redirects?

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Sep 2017 08:29:14 +1200

>    A shared network service, is a service offering where a particular L2
>    access network (i.e. wifi) is shared and used by multiple visiting
>    devices (i.e. subscribers). 

I'm pretty sure that you mean "e.g.", not "i.e.", in both of those parentheses.

This version still does not clarify whether a "unicast" RA means one sent to
a unicast Layer 3 address at a unicast Layer 2 address, or to ff02::1 at
a unicast Layer 2 address, or either. An implementer has to guess.

Regards
   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Sep 2017 21:12:18 +0000

Please add the following to Security Considerations:

  "While the practices described herein encourage L3 operations that would
    forward all traffic through a provider managed First Hop Router, peer to peer
    communications are still possible unless L2 mechanisms are also employed
    in some fashion outside the scope of this document."

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, September 13, 2017 7:04 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mark Smith <[email-masked]>
Date: Thu, 14 Sep 2017 08:00:38 +1000

On 14 Sep. 2017 07:12, "Templin, Fred L" <[email-masked]> wrote:

  "While the practices described herein encourage L3 operations that would
    forward all traffic through a provider managed First Hop Router,

That needs to be adjusted slightly to be accurate. Unless an ND proxy is
used, LL traffic cannot be made to go though the first hop router.

It'd be worth everybody interested in this draft having a read of

IP over Intentionally Partially Partitioned Links

https://tools.ietf.org/html/draft-intf-intarea-ippl-00

It recommends against using an ND proxy.

It should also probably be referenced by this draft.

Regards,
Mark.

peer to peer

Thanks - Fred

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 13 Sep 2017 15:03:34 -0700

I would instead say the opposite, i.e., call attention to what is in fact
one of the the main benefits of this document. Suggested text:

The practices described in this document make it very simple for networks
to implement robust isolation between clients at layer 2. The network can
simply ensure that devices cannot send packets to each other except through
the first-hop router. This will automatically provide robust protection
against attacks between devices that rely on link-local ICMPv6 packets,
such as DAD reply spoofing, ND cache exhaustion, malicious redirects, and
rogue RAs. This form of protection is much more scalable and robust than
alternative mechanisms such as DAD proxying, forced forwarding, or ND
snooping.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Sep 2017 22:10:55 +0000

I like my text better; it is simpler, and says what is necessary and sufficient.
At a minimum, it has to admit that peer to peer is possible unless somehow
prevented by L2 mechanisms.

Thanks - Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Wednesday, September 13, 2017 3:04 PM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

I would instead say the opposite, i.e., call attention to what is in fact one of the the main benefits of this document. Suggested text:

The practices described in this document make it very simple for networks to implement robust isolation between clients at layer 2. The network can simply ensure that devices cannot send packets to each other except through the first-hop router. This will automatically provide robust protection against attacks between devices that rely on link-local ICMPv6 packets, such as DAD reply spoofing, ND cache exhaustion, malicious redirects, and rogue RAs. This form of protection is much more scalable and robust than alternative mechanisms such as DAD proxying, forced forwarding, or ND snooping.

On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Please add the following to Security Considerations:

Thanks - Fred

> From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Sep 2017 22:18:26 +0000

Hi Mark,

From: Mark Smith [mailto:[email-masked]]
Sent: Wednesday, September 13, 2017 3:01 PM
To: Templin, Fred L <[email-masked]>
Cc: v6ops list <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

On 14 Sep. 2017 07:12, "Templin, Fred L" <[email-masked]<mailto:[email-masked]>> wrote:
Please add the following to Security Considerations:

That needs to be adjusted slightly to be accurate. Unless an ND proxy is used, LL traffic cannot be made to go though the first hop router.

Ø    Right, the text does not take LL traffic into consideration. I borrowed

Ø    the text from the main portion of the document, so your comment

Ø    probably applies there as well.

Regards,
Mark.

peer to peer

Thanks - Fred

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 13 Sep 2017 15:23:22 -0700

That you like your text better is not surprising. :-)

But the reality is that peer-to-peer communication on a public network
enables a whole class of attacks, and the major advantage of the
prefix-per-host model is that it makes it possible to defend against those
attacks in a scalable way. This model allows implementing security in a
scalable way, and this draft should say that.

At a minimum, if we want to say that peer-to-peer is possible, we *must*
also say that peer-to-peer communication enables a whole class of attacks
that can be very simply defended against if it not allowed.

On Wed, Sep 13, 2017 at 3:10 PM, Templin, Fred L <[email-masked]>
wrote:

> *From:* Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Wednesday, September 13, 2017 3:04 PM
> *To:* Templin, Fred L <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-p
> refix-per-host-08.txt
>
>
>
> On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L <
> [email-masked]> wrote:
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Sep 2017 22:31:12 +0000

Aside from Mark Smith’s comment on LLs, I still don’t get what you think
is insufficient in the text I offered. The threat model for peer-to-peer is
certainly outside the scope of this document and does not apply in cases
where peer-to-peer is desirable.

Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Wednesday, September 13, 2017 3:23 PM
To: Templin, Fred L <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

But the reality is that peer-to-peer communication on a public network enables a whole class of attacks, and the major advantage of the prefix-per-host model is that it makes it possible to defend against those attacks in a scalable way. This model allows implementing security in a scalable way, and this draft should say that.

At a minimum, if we want to say that peer-to-peer is possible, we *must* also say that peer-to-peer communication enables a whole class of attacks that can be very simply defended against if it not allowed.

On Wed, Sep 13, 2017 at 3:10 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
I like my text better; it is simpler, and says what is necessary and sufficient.
At a minimum, it has to admit that peer to peer is possible unless somehow
prevented by L2 mechanisms.

Thanks - Fred

From: Lorenzo Colitti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, September 13, 2017 3:04 PM
To: Templin, Fred L <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

Thanks - Fred

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Sep 2017 05:47:24 +0200

Le 14/09/2017 à 00:23, Lorenzo Colitti a écrit :
> prefix-per-host model is that it makes it possible to defend against 
> those attacks in a scalable way. This model allows implementing security 
> in a scalable way, and this draft should say that.
> 
> also say that peer-to-peer communication enables a whole class of 
> attacks that can be very simply defended against if it not allowed.

Well, there is SeND.

Alex

> 
> On Wed, Sep 13, 2017 at 3:10 PM, Templin, Fred L 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     I like my text better; it is simpler, and says what is necessary and
>     sufficient.____
> 
>     At a minimum, it has to admit that peer to peer is possible unless
>     somehow____
> 
>     prevented by L2 mechanisms.____
> 
>     __ __
> 
>     Thanks - Fred____
> 
>     __ __
> 
>     *From:*Lorenzo Colitti [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *To:* Templin, Fred L <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [v6ops] I-D Action:
>     draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt____
> 
>     __ __
> 
>     I would instead say the opposite, i.e., call attention to what is in
>     fact one of the the main benefits of this document. Suggested text:____
> 
>     __ __
> 
>     The practices described in this document make it very simple for
>     networks to implement robust isolation between clients at layer 2.
>     The network can simply ensure that devices cannot send packets to
>     each other except through the first-hop router. This will
>     automatically provide robust protection against attacks between
>     devices that rely on link-local ICMPv6 packets, such as DAD reply
>     spoofing, ND cache exhaustion, malicious redirects, and rogue RAs.
>     This form of protection is much more scalable and robust than
>     alternative mechanisms such as DAD proxying, forced forwarding, or
>     ND snooping.____
> 
>     __ __
> 
>     __ __
> 
>     __ __
> 
>     On Wed, Sep 13, 2017 at 2:12 PM, Templin, Fred L
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:____
> 
>         Thanks - Fred____
>          > From: v6ops [mailto:[email-masked]
>         <mailto:[email-masked]>] On Behalf Of
>         [email-masked] <mailto:[email-masked]>
>          > To: [email-masked] <mailto:[email-masked]>
>          > Cc: [email-masked] <mailto:[email-masked]>
>          > Subject: [v6ops] I-D Action:
>         draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
>          >
>          >
>          >       Filename        :
>         draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt
>          >       Pages           : 9
>          >       Date            : 2017-09-13
>          >
>          > Abstract:
>         <https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/>
>          >
>         <https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08>
>          >
>         <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-08>
>          >
>         <https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-unique-ipv6-prefix-per-host-08>
>          >
>          >
>          > until the htmlized version and diff are available at
>         tools.ietf.org <http://tools.ietf.org>.
>          >
>         <ftp://ftp.ietf.org/internet-drafts/>
>          >
>          > [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/v6ops>____
> 
>     __ __
> 
> 
> 
>

---

From: Tim Chown <[email-masked]>
Date: Thu, 14 Sep 2017 09:43:29 +0000

On 13 Sep 2017, at 23:03, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:

+1 to this. It improves the document and further clarifies its applicability and benefits.

Tim

Thanks - Fred

> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Sep 2017 17:47:00 +0000

Below:

From: Tim Chown [mailto:[email-masked]]
Sent: Thursday, September 14, 2017 2:43 AM
To: Lorenzo Colitti <[email-masked]>
Cc: Templin, Fred L <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-08.txt

The practices described in this document make it very simple for networks to implement robust isolation between clients at layer 2.

?  The practices described in this document do not make it any simpler for networks to implement

?  robust isolation between clients at layer 2. If networks are going to implement layer 2 isolation,

?  it does not matter whether /not the practices described in this document are used.

The network can simply ensure that devices cannot send packets to each other except through the first-hop router. This will automatically provide robust protection against attacks between devices that rely on link-local ICMPv6 packets, such as DAD reply spoofing, ND cache exhaustion, malicious redirects, and rogue RAs. This form of protection is much more scalable and robust than alternative mechanisms such as DAD proxying, forced forwarding, or ND snooping.

?    These are all artifacts of the layer 2 isolation; not of the L3 practices described in this document.

Tim

Thanks - Fred

---

From: David Farmer <[email-masked]>
Date: Thu, 14 Sep 2017 13:16:33 -0500

On Thu, Sep 14, 2017 at 12:47 PM, Templin, Fred L <[email-masked]

> Below:
>
>
>
> *From:* Tim Chown [mailto:[email-masked]]
>
> On 13 Sep 2017, at 23:03, Lorenzo Colitti <[email-masked]> wrote:
>
>
>
> to implement robust isolation between clients at layer 2.
>
>
>
> Ø  The practices described in this document do not make it any simpler
> for networks to implement
>
> Ø  robust isolation between clients at layer 2. If networks are going to
> implement layer 2 isolation,
>
> Ø  it does not matter whether /not the practices described in this
> document are used.
>
> I disagree, layer 2 isolation breaks a classic IPv6 subnet, without
something like DAD or ND proxy, or ND snooping.  This model of doing Layer
3, allows layer 2 isolation without any of that, which is cleaner and more
scalable like Lerenzo's text says.

The network can simply ensure that devices cannot send packets to each
> other except through the first-hop router. This will automatically provide
> robust protection against attacks between devices that rely on link-local
> ICMPv6 packets, such as DAD reply spoofing, ND cache exhaustion, malicious
> redirects, and rogue RAs. This form of protection is much more scalable and
> robust than alternative mechanisms such as DAD proxying, forced forwarding,
> or ND snooping.
>
>
>
> Ø    These are all artifacts of the layer 2 isolation; not of the L3
> practices described in this document.
>
>
Yes, they are artifacts of the layer2 isolation, which is enable by this
model of doing Layer 3, with ND proxy...

> applicability and benefits.

 Yep, +1 to Lerenzo's text

Thanks

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

---

From: David Farmer <[email-masked]>
Date: Thu, 14 Sep 2017 13:32:36 -0500

> I'm pretty sure that you mean "e.g.", not "i.e.", in both of those

Actually I think "i.e." is fine in the second case, "(in other words
subscribers)" seems appropriate to the sentence, which is more or less what
 "i.e." means.

But, yes in the first case "e.g." or "(for example wifi)" would seem more
appropriate to the sentence.

> a unicast Layer 2 address, or either. An implementer has to guess.

+1, while adding the reference to RFC6085, helps a little, I think this is
worth a few more words to make it explicitly clear.  Also, mentioning how
periodic RA are intended to be handled in addition to RAs in response to an
RS.  I provided some text previously, use it if you like.

Regards

Thanks

---

From: Tim Chown <[email-masked]>
Date: Thu, 14 Sep 2017 22:20:55 +0000

> On 14 Sep 2017, at 19:32, David Farmer <[email-masked]> wrote:
> 
> 
> 
> On Wed, Sep 13, 2017 at 3:29 PM, Brian E Carpenter <[email-masked]> wrote:
> Actually I think "i.e." is fine in the second case, "(in other words subscribers)" seems appropriate to the sentence, which is more or less what  "i.e." means.
> 
> But, yes in the first case "e.g." or "(for example wifi)" would seem more appropriate to the sentence.
>  
> +1, while adding the reference to RFC6085, helps a little, I think this is worth a few more words to make it explicitly clear.  Also, mentioning how periodic RA are intended to be handled in addition to RAs in response to an RS.  I provided some text previously, use it if you like.    

Yes, this small change would improve the draft.

Tim