Subject: [secdir] SecDir review of draft-ietf-v6ops-64share-09

From: Yaron Sheffer <[email-masked]>
Date: Wed, 19 Feb 2014 17:49:44 +0200

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document describes two options of providing hosts behind a 3GPP UE 
(e.g., cellular router) with an IPv6 network prefix, in networks that do 
not support IPv6 prefix delegation. The document is explicitly 
non-normative.

Summary

The document is ready to progress.

Details

- I don't understand why the first scenario (sec. 4.2) is even useful, 
i.e. why allocate the /64 to the LAN (and not just settle for a 
link-local prefix) when the UE does not have an address on the 3GPP 
link, and so cannot route traffic to the Internet?

- Despite the non-normative status of the document, I think the security 
considerations deserve stronger wording. I suggest to replace "shall be 
considered" by "SHOULD be applied".

- I would suggest that the security considerations also mention the 
privacy implications of having a (typically) small number of devices, 
all within a single unchanging network prefix. I *believe* this is 
behind the discussion of RFC 4941 is Sec. 4.3, but I would rather have 
the threat spelled out.

Thanks,
      Yaron

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 19 Feb 2014 16:59:00 +0100

Dear Yaron,

Many thanks for your review.

> -----Original Message-----
> From: Yaron Sheffer [mailto:[email-masked]]
> Sent: Wednesday, February 19, 2014 4:50 PM
> To: [email-masked]; draft-ietf-v6ops-
> [email-masked]; [email-masked]
> Subject: SecDir review of draft-ietf-v6ops-64share-09
> 
> I have reviewed this document as part of the security
> directorate's ongoing effort to review all IETF documents
> being processed by the IESG.
> These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs
> should treat these comments just like any other last call
> comments.
> 
> This document describes two options of providing hosts behind
> a 3GPP UE (e.g., cellular router) with an IPv6 network
> prefix, in networks that do not support IPv6 prefix
> delegation. The document is explicitly non-normative.
> 
> Summary
> 
> - I don't understand why the first scenario (sec. 4.2) is
> even useful, i.e. why allocate the /64 to the LAN (and not
> just settle for a link-local prefix) when the UE does not
> have an address on the 3GPP link, and so cannot route traffic
> to the Internet?

This scenario is discussing a case where the 3GPP interface assigned
GUA prefix will be moved to the LAN link, the 3GPP link will still
be LLA numbered.

> - Despite the non-normative status of the document, I think
> the security considerations deserve stronger wording. I
> suggest to replace "shall be considered" by "SHOULD be
> applied".

OK, we will consider it.

> - I would suggest that the security considerations also
> mention the privacy implications of having a (typically)
> small number of devices, all within a single unchanging
> network prefix. I *believe* this is behind the discussion of
> RFC 4941 is Sec. 4.3, but I would rather have the threat
> spelled out.

OK, the lifetime of a prefix is bound to the lifetime of the network
attach (context), once the device (UE) re-attaches a new prefix will 
be assigned by the network. This solution shall be understood as
an interim one bridging the gap till DHCP-PD will be widely available.
 
>       Yaron

Cheers,
Ales

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 20 Feb 2014 10:47:20 +0200

[Dropped IESG]

Hi Ales, please see below.

Thanks,
	Yaron

>> From: Yaron Sheffer [mailto:[email-masked]]

[...]

> GUA prefix will be moved to the LAN link, the 3GPP link will still

So can Internet traffic from the LAN be routed through the 3GPP link in 
this case? It looks funny to me to have a default route with an LLA.

If this is a small independent network with no Internet routing, you 
don't really need a GUA prefix.

> an interim one bridging the gap till DHCP-PD will be widely available.

This "interim" period can be a few years, and in the meantime we have a 
large privacy issue here. Does the provider normally enforce periodic 
reassignment of the network prefix? Otherwise I can see prefixes 
remaining valid for months (for small routers of course, not for phones).

---

From: Vízdal Aleš <[email-masked]>
Date: Thu, 20 Feb 2014 10:55:23 +0100

Hi Yaron,

Please see inline.

> even
> >> useful, i.e. why allocate the /64 to the LAN (and not just
> settle for
> >> a link-local prefix) when the UE does not have an address
> on the 3GPP
> > GUA prefix will be moved to the LAN link, the 3GPP link
> will still be
> > LLA numbered.
> 
> So can Internet traffic from the LAN be routed through the
> 3GPP link in this case? 

Yes, that's the intention.

>It looks funny to me to have a default route with an LLA.

If you do SLAAC, the on-link router will send you the RA message
whose source IPv6 address will be LLA and will be also used
as the default route. (as per Neighbor Discovery RFC)

> If this is a small independent network with no Internet
> routing, you don't really need a GUA prefix.

The use-case is your mobile phone acting as a WiFi access point
for your notebook while travelling or while being at home. There
is a need for GUA for the tethered devices. (IPv4 approach would
be private IPV4+NAT44)

> >> - Despite the non-normative status of the document, I
> think the
> >> security considerations deserve stronger wording. I
> suggest to
> >> replace "shall be considered" by "SHOULD be applied".
> >
> > OK, we will consider it.
> >
> mention the
> >> behind the discussion of RFC 4941 is Sec. 4.3, but I would
> rather
> >> have the threat spelled out.
> >
> > be assigned by the network. This solution shall be
> understood as an
> > interim one bridging the gap till DHCP-PD will be widely
> available.
> 
> This "interim" period can be a few years, and in the meantime
> we have a large privacy issue here. Does the provider
> normally enforce periodic reassignment of the network prefix?
> Otherwise I can see prefixes remaining valid for months (for
> small routers of course, not for phones).

You're right, the interim solutions tend to become permanent.

Some networks do, some don't. Please note that the mobile phones
are getting a /64 these days, so the potential privacy issue is
already there, we're just extending the same /64 to a small LAN.

A user may re-load the device to get a new prefix if their network
is not enforcing a new prefix every n hours.

Cheers,
Ales