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

[Vízdal Aleš <[e-mail]>]

Hi Yaron,

Please see inline.

> >> -----Original Message-----
> >> From: Yaron Sheffer [mailto:[e-mail]]
> 
> [...]
> 
> >> 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?
> >
> > 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.
> 
> 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.
> >
> >> - 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.
> 
> 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.

> >> Thanks,
> >>        Yaron

Cheers,
Ales