Subject: [homenet] IPv6 & firewall config in a home net

From: <[email-masked]>
Date: Mon, 2 Sep 2019 15:55:39 +0000

Hey,

Mal here. IETF attendee since 2012 ;)

I have a home networking question with respect to IPv6 standards, I'm hoping to use you as a sounding board first before I take it to v6ops.

The scenario here is a home / soho network situation where the user wants to host a service, lets say its a webserver, but really could be any hosted application, importantly using IPv6. The router is setup to use SLAAC only.

The ISP offers IPv6 GUA addressing in a non-stable manor, its "sticky" but at some point in the future it might change (BNG reboot for example), so the user will use DynDNS provider to provide a stable name for their service, this sounds OK so far.

The user has to allow the webserver port, 443 in their router GUI firewall to allow the traffic in, sounds simple enough. Importantly it should be to that webserver device only.

Now the tricky part....

Since in this scenario the webserver device is using privacy extensions, it has a bunch of IPv6 GUA addresses and no EUI-64 and
- It has Temporary addressing (which will regularly change)
- It has a "Permanent" address (which is the one the webserver will want to use)

Does this sound reasonable and make sense so far ? Cool.

In the router GUI the user is presented with a list of "devices" for which the router can open up TCP 443 in the firewall.

It is reasonable to assume the user does not want to type in the Permanent IPv6 address of the device, as it is poor CX and anyway it will change in the future (possibly due to a network change / BNG restart etc as mentioned)

Current routers on the market I have come across have either:

  1.  Open the port to the current temporary address only which means that inbound connections on the port usually fails right away (if the webserver is not listening on that address) - or fail after the temporary address changes.
  2.  Opens the port to the correct address (by chance)
     *   - But then fails at some point in the future when the network prefix changes (as router drops the rule when the prefix changes).
  3.  Opens the port to some or ALL addresses currently (& sometimes historically) associated with the mac address of the device  (not great for security - spoofing? )
     *   But even that sometimes excludes the permanent address
  4.  Opens the port to all addresses on LAN (not great for security at all)

  *   Basically the routers firewall config gui doesn't know reliably which device address is the permanent one.

  *   Should there exist a mechanism to signal to the router or the router can accurately learn which of the devices addresses should be used for configuration in the firewall ?

Is this a problem - have I missed something - Is it worth fixing ?

Thoughts:
This is probably a strange thing for the user to do (but I have had users trying to do it). Its usually fixed for a customer by switching off privacy extensions / using EUI-64 so basically giving the device a single address for the router gui to identify the device by.

Mal

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Sep 2019 12:31:28 -0400

Your router should be using PCP to allow servers to open ports and should have a GUI to authorize that, or better yet support MUD profiles and use the GUI to control that. 

Sent from my iPhone

> On Sep 2, 2019, at 11:55, [email-masked] wrote:
> 
> 
> Hey,
>  
> I have a home networking question with respect to IPv6 standards, I’m hoping to use you as a sounding board first before I take it to v6ops.
>  
> Now the tricky part….
> Open the port to the current temporary address only which means that inbound connections on the port usually fails right away (if the webserver is not listening on that address) – or fail after the temporary address changes.
> Opens the port to the correct address (by chance)
> - But then fails at some point in the future when the network prefix changes (as router drops the rule when the prefix changes).
> Opens the port to some or ALL addresses currently (& sometimes historically) associated with the mac address of the device  (not great for security – spoofing? )
> But even that sometimes excludes the permanent address
> Opens the port to all addresses on LAN (not great for security at all)
>  
> Basically the routers firewall config gui doesn’t know reliably which device address is the permanent one.
>  
> Should there exist a mechanism to signal to the router or the router can accurately learn which of the devices addresses should be used for configuration in the firewall ?
>  
> Is this a problem – have I missed something – Is it worth fixing ?
>  
>  
> Thoughts:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Sep 2019 13:47:42 -0400

<[email-masked]> wrote:
    > I have a home networking question with respect to IPv6 standards, I'm
    > hoping to use you as a sounding board first before I take it to v6ops.

okay.

    > The scenario here is a home / soho network situation where the user
    > wants to host a service, lets say its a webserver, but really could be
    > any hosted application, importantly using IPv6. The router is setup to
    > use SLAAC only.

Understood.  Why is SLAAC important here?

    > The ISP offers IPv6 GUA addressing in a non-stable manor, its "sticky"
    > but at some point in the future it might change (BNG reboot for
    > example), so the user will use DynDNS provider to provide a stable name
    > for their service, this sounds OK so far.

sure, or can use the front-end naming mechanism that this WG is working on.

    > The user has to allow the webserver port, 443 in their router GUI
    > firewall to allow the traffic in, sounds simple enough. Importantly it
    > should be to that webserver device only.

Fair enough.

    > Since in this scenario the webserver device is using privacy
    > extensions, it has a bunch of IPv6 GUA addresses and no EUI-64 and

    > Does this sound reasonable and make sense so far ? Cool.

Yes, so an rfc7217 address.

    > In the router GUI the user is presented with a list of "devices" for
    > which the router can open up TCP 443 in the firewall.

How does the router get this list?  This is important.  Is this a list of
names, or a list of addresses?

    > It is reasonable to assume the user does not want to type in the
    > Permanent IPv6 address of the device, as it is poor CX and anyway it
    > will change in the future (possibly due to a network change / BNG
    > restart etc as mentioned)

It seems reasonable that the user is given a list of names.
The names would ideally come from DNS-SD's SRP.

    > 1.  Open the port to the current temporary address only which means
    > that inbound connections on the port usually fails right away (if the
    > webserver is not listening on that address) - or fail after the
    > temporary address changes.

that's not useful.

    > *   - But then fails at some point in the future when the network
    > prefix changes (as router drops the rule when the prefix changes).

Assuming that the prefix change is make-before-break (which we do not clearly
know how to do on the WAN side, I think), then the web server should
configure with the same rfc7212 IID, but a new prefix.

    > 3.  Opens the port to some or ALL addresses currently (& sometimes
    > historically) associated with the mac address of the device  (not great
    > for security - spoofing? )

Hmm. How does it know those addresses are all the same device?
If the router can tell, maybe the privacy addresses aren't very private :-)

    > 4.  Opens the port to all addresses on LAN (not great for security at all)

no.

    > *   Basically the routers firewall config gui doesn't know reliably
    > which device address is the permanent one.

    > *   Should there exist a mechanism to signal to the router or the
    > router can accurately learn which of the devices addresses should be
    > used for configuration in the firewall ?

    > Is this a problem - have I missed something - Is it worth fixing ?

Yes, it's worth fixing.
Note that RFC8520 (MUD) could also be used by the web server to announce it's
need.  In particular if the web server is running on a multi-purpose host,
having it configure an extra rfc7217 address JUST for it, and then using
DHCPv6 to communicate it's MUD file would make sense.
The router owner would need to affirm that this is desired communications.
(Yes, there are missing APIs in general-purpose operating systems to make
this happen)

    > Thoughts:
    > This is probably a strange thing for the user to do (but I have had
    > users trying to do it). Its usually fixed for a customer by switching
    > off privacy extensions / using EUI-64 so basically giving the device a
    > single address for the router gui to identify the device by.

Being able to open connections into services, particularly doing so for some
subset of the Internet (your alarm monitoring company, work or mobile access
to you nanny cam, etc) is one of the "killer app" for IPv6 in the home.
So I don't think it's strange, and it has to "just work" for users without
dances.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Sep 2019 13:58:15 -0400

Ted Lemon <[email-masked]> wrote:
    > Your router should be using PCP to allow servers to open ports and
    > should have a GUI to authorize that, or better yet support MUD profiles
    > and use the GUI to control that.

I meant to mention PCP as well.
Question: do PCP messages always go to the default route?  I re-read 6887 and
that was unclear. RFC7488 did not clarify for me.

How does it work if there are multiple layers of router?

---

From: Bob Hinden <[email-masked]>
Date: Wed, 4 Sep 2019 11:25:45 -0700

Mal,

To your last point:

> On Sep 2, 2019, at 8:55 AM, [email-masked] wrote:
> 
> 
> 
> 

Seems to me that if you want to have a home web server, then it will need to have a registered DNS name.   This should be a stable IPv6 address.  We no longer recommend that EUI-64 be used to create stable IPv6 addresses, see RFC 8064.

Once a DNS name is assigned, that could be used in the router’s configuration to allow access to the web server.

Bob

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 04 Sep 2019 21:04:58 +0200

> Question: do PCP messages always go to the default route?

Yes, at least according to 6887.

> I re-read 6887 and that was unclear.

Section 8.1:

       the default router list (for IPv4 and IPv6) is used as the list of
       PCP server(s).

[...]

   For the purposes of this document, only a single PCP server address
   is supported.  Should future specifications define configuration
   methods that provide a longer list of PCP server addresses, those
   specifications will define how clients select one or more addresses
   from that list.

> RFC7488 did not clarify for me.

Yeah, I'm not quite sure what it's about.

-- Juliusz

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Thu, 5 Sep 2019 15:45:52 +0200

[email-masked] wrote on 02/09/2019 17:55:
> I have a home networking question with respect to IPv6 standards, I’m 
> but at some point in the future it might change (BNG reboot for example),
>
IMHO Expected behavior. Many European data protection people consider an 
IP(v6) address to be privacy-sensitive personal data.
That will likely mean regular renumbering of IA PD by ISP's as the norm 
rather than the exception.
>
> so the user will use DynDNS provider to provide a stable name for 
> their service, this sounds OK so far.
>
External users should also be using a name rather than a (time variant) 
IPv6 address.

Please be so kind as to review our draft 
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-08

[Hopefully a new version will be forthcoming soon]

This is precisely one of our use-cases.

> - It has a "Permanent" address (which is the one the webserver will 
The webserver should not be using privacy extensions for inbound sessions.

It really should be using https://tools.ietf.org/html/rfc7217
> restart etc as mentioned)
Correct.
>     that inbound connections on the port usually fails right away (if
>     the webserver is not listening on that address) – or fail after
>     the temporary address changes.
>      1. - But then fails at some point in the future when the network
>     historically) associated with the mac address of the device  (not
>     great for security – spoofing? )
>      1. But even that sometimes excludes the permanent address
>   * Basically the routers firewall config gui doesn’t know reliably
>     router can accurately learn which of the devices addresses should
>     be used for configuration in the firewall ?
>
Yes. via PCP RFC6887 et al.
>  *
Yes. - RFC8520? although there's still a gap for policy IMHO (does a 
user want to accept what the manufacturer suggested) - Yes.
> single address for the router gui to identify the device by.
I personally hope this becomes more common, to avoid the need for NAT, 
rendezvous points, dependence on central certificate instances etc.

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Sep 2019 17:17:01 +0100

> rather than the exception.

I get a bit of both. If there's a power outage or some other
kinds of service outage I don't get, then I get renumbered
when some bit of ISP kit reboots. Happens about 2-3 times a
year maybe.

S.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Sep 2019 12:31:31 -0400

> that was unclear. RFC7488 did not clarify for me.

PCP requests go to the PCP server the client chooses.   PCP servers can currently only be advertised using DHCP.   If there are multiple PCP servers, the client has to register with all of them.   A PCP server should know whether it makes sense to register a port/address combination with it.

> How does it work if there are multiple layers of router?

I believe that the PCP server on the inner router communicates with the PCP server on the outer router, but I’d have to double check.

> rather than the exception.

It should be assumed to be the rule, so that if it is the rule, it is handled correctly.

> configure with the same rfc7212 IID, but a new prefix.

I don’t think there’s any need for the IID to be persistent.   Make-before-break is accomplished by deprecating the old prefix when the new prefix is added.   This is trivial to do; whether it is in fact done is a different matter.   I think that at present the client would have to notice that it’s happened.

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Fri, 6 Sep 2019 08:30:51 +0200

Ted Lemon wrote on 05/09/2019 18:31:
> On Sep 2, 2019, at 1:47 PM, Michael Richardson<[email-masked]>  wrote:

Agreed.

Using RFC7217 will anyway almost certainly guarantee that the IID will 
also change if the prefix changes.

The prefix is included in the function that generates candidate IID's.

   RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)

That was done to prevent tracking when people move between wifi hotspots.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 6 Sep 2019 08:59:11 +0200 (CEST)

On Thu, 5 Sep 2019, Ray Hunter (v6ops) wrote:

> IP(v6) address to be privacy-sensitive personal data. That will likely 
> mean regular renumbering of IA PD by ISP's as the norm rather than the 
> exception.

This is the first time I've seen anyone make this claim (I guess related 
to GDPR). I've gone through GDPR review and talked to others who have done 
the same, and I from a GDPR point of view there is no reason to renumber 
on a regular basis. From what I can tell, renumbering at some frequency 
makes no difference from a GDPR point of view. The addresses are privacy 
sensitive regardless if you change them frequently or not.

My experience is that the frequent renumbering is a local market practice 
that people in that market got used to. As a swedish user, I hadn't heard 
of this practice until I started talking about these things with people 
that ran/experienced ISPs in other nations. The defaults are also 
different.

Some markets have frequent renumbering (some even reset the PPPoE session 
once per day, which is a flash renumbering eevent), some never renumber 
unless there is a big network change (I've had the same IPv6 prefix now 
for a year).

The conclusion is that we need to create solutions that handle both these 
cases.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 06 Sep 2019 12:00:40 +0200

I will say the norm is in the other way around, according to the IPv6 Survey that I run continuously.

If I recall correctly, the last time I checked the data, over 70% of the responders use persistent prefixes. There is an old presentation (I'm not sure if is the last one I did, as I presented that many times and in many foras), that shows a similar % (but the survey is still running, so I could check new data every few months):

https://indico.uknof.org.uk/event/41/contributions/542/attachments/712/866/bcop-ipv6-prefix-v9.pdf

It is true that addresses are considered in all the EU personal data, but there is NOT such rule in any country (as I know), neither in the GDPR, that forces the renumbering or the use of non-persistent prefixes. There was rumors that Germany was doing that, but it is not true.

See RIPE690 https://www.ripe.net/publications/docs/ripe-690.
  
Regards,
Jordi
@jordipalet

El 6/9/19 8:59, "homenet en nombre de Mikael Abrahamsson" <[email-masked] en nombre de [email-masked]> escribió:

    

    

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Sep 2019 12:59:54 +0100

On Sep 2, 2019, at 1:47 PM, Michael Richardson <[email-masked]> wrote:
    >         Assuming that the prefix change is make-before-break (which we
    > do not clearly know how to do on the WAN side, I think), then the web
    > server should configure with the same rfc7212 IID, but a new prefix.

To be clear, the issue of the make-before-break is on the WAN DHCPv6-PD side.
I believe that we concluded that it's possible to do in existing
specifications, but not well enough implemented at both sides (ISP/CPE)
device to depend upon.

Ted Lemon wrote on 05/09/2019 18:31:
    >     I don’t think there’s any need for the IID to be persistent.
    > Make-before-break is accomplished by deprecating the old prefix when
    > the new prefix is added.  This is trivial to do; whether it is in fact
    > done is a different matter.  I think that at present the client would
    > have to notice that it’s happened.

    > That was done to prevent tracking when people move between wifi

But, a host running a web server that wants to be in the same place could
keep the same RID once generated.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Sun, 08 Sep 2019 13:02:59 +0100

Mikael Abrahamsson <[email-masked]> wrote:
    > This is the first time I've seen anyone make this claim (I guess
    > related to GDPR). I've gone through GDPR review and talked to others
    > who have done the same, and I from a GDPR point of view there is no
    > reason to renumber on a regular basis. From what I can tell,
    > renumbering at some frequency makes no difference from a GDPR point of
    > view. The addresses are privacy sensitive regardless if you change them
    > frequently or not.

It would be nice to get a public legal opinion published somewhere, so that
it can't be used as a marketing excuse.

    > The conclusion is that we need to create solutions that handle both
    > these cases.

Agreed, and it would be nice if it wasn't a flash renumber, which resetting
of the PPPoE session can causes.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 8 Sep 2019 08:20:11 -0400

> On Sep 8, 2019, at 07:59, Michael Richardson <[email-masked]> wrote:
> 

Since the prefix is changing, keeping the host ID the same makes no difference. Presumably the server’s host name will be what’s invariant.

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Sun, 8 Sep 2019 14:48:23 +0200

Mikael Abrahamsson wrote on 06/09/2019 08:59:
>> IMHO Expected behavior. Many European data protection people consider 
>> an IP(v6) address to be privacy-sensitive personal data. That will 
>> likely mean regular renumbering of IA PD by ISP's as the norm rather 
>> than the exception.
>
> view. The addresses are privacy sensitive regardless if you change 
> them frequently or not.
This last sentence is key.

FYI The opinion I read was as follows:

"The same also applies to IP addresses. If the controller has the legal 
option to oblige the provider to hand over additional information which 
enable him to identify the user behind the IP address, this is also 
personal data."

So if the provider intentionally destroys any method of linking an IP 
address to a user behind an address (by regularly renumbering using 
pseudo-random prefixes) then by the opposite argument the IP address 
shouldn't be considered personal data any more.

This is a method that I've also seen used to pseudo-anonymize MAC 
addresses logged via wifi in a building management system. The MAC 
addresses were hashed with a pseudo random key that rotated every day, 
and the key was not stored anywhere. So the location data could be 
tracked accurately for an individual device over a period of 24 hours, 
but the privacy people considered this good enough that the result 
wasn't considered as personal data, because there was no practical way 
to work backwards from the hashed addressed to the movements of an 
individual device carried by an individual person.

I ain't a lawyer.
>
> My experience is that the frequent renumbering is a local market 
> practice that people in that market got used to. As a swedish user, I 
> hadn't heard of this practice until I started talking about these 
> things with people that ran/experienced ISPs in other nations. The 
> defaults are also different.
>
> Some markets have frequent renumbering (some even reset the PPPoE 
> session once per day, which is a flash renumbering eevent), some never 
> renumber unless there is a big network change (I've had the same IPv6 
> prefix now for a year).
>
I agree with your conclusion, so the rest is pretty much a moot point 
for Homenet.