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

mal.hubert@bt.com wrote on 02/09/2019 17:55:
>
> 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),
>
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.

> 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)
>
The webserver should not be using privacy extensions for inbound sessions.

It really should be using https://tools.ietf.org/html/rfc7217
>
> 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)
>
Correct.
>
> 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)
>      1. - 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? )
>      1. 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 ?
>
Yes. via PCP RFC6887 et al.
>
>  *
>
>
> Is this a problem – have I missed something – Is it worth fixing ?
>
Yes. - RFC8520? although there's still a gap for policy IMHO (does a 
user want to accept what the manufacturer suggested) - Yes.
>
> 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.
>
I personally hope this becomes more common, to avoid the need for NAT, 
rendezvous points, dependence on central certificate instances etc.
>
> Mal
>
>
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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