Hi Wes, On 27.09.2011 16:53, George, Wes wrote:
> WEG] A firewall/gateway can do this regardless of the address space > that you are using. What you're proposing is a use case similar to the > IPv4 model of using RFC1918 addresses + NAT/NAPT at the edge of the > private network, and you will not find good support for extending that > model to IPv6 because it breaks end to end connectivity and there are > none of the address constraints that are present in IPv4 - everything > that wants a globally unique address can get one. Even if there is a Oh no, I definitely hate NATs and don't want them in IPv6. I also like the end-to-end principle and e2e transparency, but security is unluckily an important reason to introduce a security gateway here. The difference to NATs is that they try to be transparent for the ECUs, whereas the security gateway is an explicitly modeled control point. You definitely don't want that all ECUs (electronic control units) in your car are reachable from the Internet thereby permitting attackers to compromise your car, e.g., firing up the airbag while driving etc. The car onboard network should operate independently from any "outside connectivity" and addresses, but some services will likely require intermittent connectivity with the Internet, e.g., map updates for the navigation system, web radio streaming etc. So total isolation is probably not possible. > legitimate reason for not wanting that end to end connectivity in your > case, if we make an IPv6 version of RFC1918+NAT available, there's > nothing preventing it from being used by everyone that equates that > implementation with "better security" today in IPv4, no matter how > much we say "don't do that..." You can still use a single gateway to I'm well aware that NATs aren't a security solution and all that I'm proposing is to use a stable internal addressing for the onboard network (no matter how the car is currently connected to the Internet) and to use a security gateway/proxy when communication to the Internet is somehow required. > control how devices access the internet (and more importantly, how > the internet accesses those devices) without pushing them into ULA > space by filtering traffic as necessary at the ingress/egress point You will definitely need an address separation. Whether you use internally globally unrouted and filtered addresses from the global unicast space or ULAs probably doesn't matter so much. > without using the addresses themselves as an obfuscation mechanism. > That way you remove none of the flexibility if you end up needing > connectivity later, but retain the desired security. IMHO all fine for ordinary networks, but probably not the automotive case. > You also note uniqueness as desirable to manage potential mergers > and > conflicts between manufacturers on networks that were previously not > connected. I think that the solution here is to ensure that the gear in > question supports a relatively straightforward renumbering procedure - > divorce the network's prefix from the device ID in such a way that the > network prefix can be altered on one or both networks should they be > merged. Even if the device has a partially hard-coded address, it should > be capable of accepting a different prefix should the situation dictate > it. The 6renum working group is currently working on exactly this > problem (making renumbering easier in IPv6 enterprise deployments), and > would love to have input from you on specific considerations within the > industries that are represented in this thread. (disclaimer, I am one of > the 6renum WG chairs). Ok, interesting. The automotive scenario isn't probably a good use case here, but there may be other environments. Maybe I can come back with some examples. Thanks for your comments, Roland -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
