[IPv6]Re: Secdir telechat review of draft-ietf-6man-zone-ui-07

[Tero Kivinen <[e-mail]>]

Brian E Carpenter writes:
> >>>  For example, a typical home router may today be configured via "192.168.178.1" but not via "fe80::1%eth0"
> 
> which only makes sense by using an RFC 1918 address, so I think
> we have no choice. We could use 10.1.1.1, which is a bit more
> obvious.

Why would only RFC1918 addresses make sense there? I have seen home
routers using non RFC1918 addresses too, and they might even take
IP-address from local DHCP server and use that.

Changing text to use IPv4 addresses reserved for examples would be
best. 

> > Security considerations do list typical issues but one of the issues
> > with zone identifiers is that the set of characters it can use is
> > not defined, thus web-form, etc might have difficulties to remove
> > unsafe characters. For example entering zone identifiers of
> > "fe80::1%`echo string > /etc/config`" might allow users to cause
> > unauthorized changes to the system without proper authentication.
> > 
> > On the other hand just automatically limiting zone identifiers
> > to ascii letters and numbers does not work, as they may contain
> > some special characters like "." or "-".
> 
> That's true, and in any case RFC 4007 does not restrict the character
> set in any way, so if we add any restriction here it might break
> some existing implementations. I'm not sure that there is anything
> useful we can write here. Do you have any suggestions?

I was thinking saying that as RFC 4007 does not restrict the character
set in any way, each implementation processing zone identifiers needs
to make checks appropriate for the environment it is used in. Doing
too strict checks may make it impossible to type some zone
identifiers, making too loose checks might cause issues when unquated
special characters are passed forward.

I.e., not adding any restrictions, just add warning, that
implementations need to understand this.

The ASCII NUL character might not be the only one that needs special
processing...
-- 
[e-mail]