Re: [Full-disclosure] IPv6 security myths
Masataka == Masataka Ohta mo...@necom830.hpcl.titech.ac.jp writes: Masataka My context is IPsec in the Internet, which excludes VPNs. Masataka Do you know some major application over the Internet using Masataka IPsec with transport mode? Why the restriction of *over*? Dozens of IETF specifications are not used *over* the Internet, but only over IP. Recall that the IETF is about standardizing things over IP, the internet is only a (large) subset of that. iSCSI specifies IPsec in transport mode. L2TP specifies IPsec in transport mode (but, that's remote-access, which usually means VPNs, so you want exclude that). So you are right: IPsec in transport mode is rarely used by popular protocols. But, it is out there, often being used to secure applications that are one-offs, or whose use is not well known. That was the point of IPsec: It's a layer of security for people to use rather than invent their own. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
Michael Richardson wrote: Masataka == Masataka Ohtamo...@necom830.hpcl.titech.ac.jp writes: Masataka My context is IPsec in the Internet, which excludes VPNs. Masataka Do you know some major application over the Internet using Masataka IPsec with transport mode? Why the restriction of *over*? Dozens of IETF specifications are not used *over* the Internet, but only over IP. Because IPv6 and IPsec were designed for the Internet. See, for example, RFC1825 saying: Widespread deployment and use of IP security will require an Internet-standard scalable key management protocol. If it were possible to have a universal PKI over the Internet, IPsec could have succeeded and IPv6 security myths could have been real. However, the reality is that there can be no such thing as a universal PKI. Note again that ICMPv6 messages were considered to be authenticated by IPsec through the hypothetical universal PKI. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
In your previous mail you wrote: My context is IPsec in the Internet, which excludes VPNs. = this is a bit unfair: VPNs are the natural model for IPsec use (putting back an uniform I could talk about red and black :-). Do you know some major application over the Internet using IPsec with transport mode? Regards francis.dup...@fdupont.fr ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
Francis Dupont wrote: In your previous mail you wrote: My context is IPsec in the Internet, which excludes VPNs. = this is a bit unfair: VPNs are the natural model for IPsec use (putting back an uniform I could talk about red and black :-). It's fair as we are talking about IPsec as IPv6 security myth. It is of course that IPsec tunnel mode is used by IPv4 and/or IPv6 VPN gateways. But it does not make IPv6 more secure than IPv4. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RE: [Full-disclosure] IPv6 security myths
Perhaps I should have said deployable ... Although it is deployed in some places, and growing rapidly - I'd be surprised if your situation didn't change over then next 12-15 months ... /TJ On Oct 30, 2010 11:28 PM, Michel Py mic...@arneill-py.sacramento.ca.us wrote: TJ [trej...@gmail.com] wrote: I would be quite curious to know your definition of failure, given that IPsec is currently deployed, and working in more than a few deployments On a possibly related note, IPv6 use deployed and working too ... Failure means that, I leave in the capital city of California and I can't find a single ISP that offers native IPv6. We're in the end of 2010. And no change in sight. Tunnels? Oh yes tunnels. I had that 10 years ago. You call that deployed? Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
If you mean widespread, point to point / peer to peer IPsec - yes, there is a distinct lack of (free, easy, global) PKI out there. There are steps in the right direction though, such as MS's Direct Access ... /TJ On Oct 31, 2010 12:02 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: TJ wrote: I would be quite curious to know your definition of failure, given that IPsec is currently deployed, and working in more than a few deployments ... Sorry for lack of clarification. My context is IPsec in the Internet, which excludes VPNs. Do you know some major application over the Internet using IPsec with transport mode? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
On Oct 31, 2010, at 12:00 AM, Masataka Ohta wrote: TJ wrote: I would be quite curious to know your definition of failure, given that IPsec is currently deployed, and working in more than a few deployments ... Sorry for lack of clarification. My context is IPsec in the Internet, which excludes VPNs. That's a strange exclusion, considering VPNs have been the primary use-case for IPsec over the Internet. Do you know some major application over the Internet using IPsec with transport mode? Yes: SIP. SIP/UDP over IPsec in transport mode on the Internet is not uncommon. Arguably more common than SIP over TLS, anyway... though that's expected to change. (and of course SIP over IPsec or TLS are both noise compared with plain SIP over UDP) Also, Femtocells running various protocols typically use IPsec over the Internet, though in tunnel mode I believe - but one wouldn't think of it as being a VPN in the traditional sense. Oh, and I believe storage/SAN (FCIP, iFCP, iSCSI) use IPsec over the Internet; or at least the IPsec chip vendors seem to focus on those markets a lot. Though again in tunnel mode I think, but not a classic VPN use. The Internet is big and diverse - not everything is HTTP and DNS. ;) -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
Hadriel Kaplan wrote: Do you know some major application over the Internet using IPsec with transport mode? Yes: SIP. SIP/UDP over IPsec in transport mode on the Internet is not uncommon. Arguably more common than SIP over TLS, anyway... though that's expected to change. (and of course SIP over IPsec or TLS are both noise compared with plain SIP over UDP) Yes, IPv6 deployment also is expected to change. Also, Femtocells running various protocols typically use IPsec over the Internet, though in tunnel mode I believe - but one wouldn't think of it as being a VPN in the traditional sense. It's a traditional VPN to encrypt data to/from mobile terminals in femtocells by femtocell stations. In the same VPN, protocols to control the stations may also be carried, which does not make the VPN not traditional. Oh, and I believe storage/SAN (FCIP, iFCP, iSCSI) use IPsec over the Internet; or at least the IPsec chip vendors seem to focus on those markets a lot. Though again in tunnel mode I think, but not a classic VPN use. Are you saying the SAN is a part of the public Internet? The Internet is big and diverse - not everything is HTTP and DNS. ;) So? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
I would be quite curious to know your definition of failure, given that IPsec is currently deployed, and working in more than a few deployments ... On a possibly related note, IPv6 use deployed and working too ... /TJ On Oct 27, 2010 12:08 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Steven Bellovin wrote: The core issue was indeed that IPsec was mandated for v6. We were *very* overoptimistic about how long it would take before roll-out started in earnest. In fact, we underestimated how long it would take to get good specs for all the important pieces. We also underestimated how long IPsec would take, though that was partially (but only partially) because IPsec version 1 (RFCs 1825-1829) had to be thrown away. Quite simply, it is merely that IPsec had totally failed long before IPv6 totally failed. FYI, total failure of IPsec is not the only reason of total failure of IPv6. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Full-disclosure] IPv6 security myths
TJ [trej...@gmail.com] wrote: I would be quite curious to know your definition of failure, given that IPsec is currently deployed, and working in more than a few deployments On a possibly related note, IPv6 use deployed and working too ... Failure means that, I leave in the capital city of California and I can't find a single ISP that offers native IPv6. We're in the end of 2010. And no change in sight. Tunnels? Oh yes tunnels. I had that 10 years ago. You call that deployed? Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
TJ wrote: I would be quite curious to know your definition of failure, given that IPsec is currently deployed, and working in more than a few deployments ... Sorry for lack of clarification. My context is IPsec in the Internet, which excludes VPNs. Do you know some major application over the Internet using IPsec with transport mode? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [Full-disclosure] IPv6 security myths
Hi, Masataka, In the interest of fair and balanced discussion. It is of course that, merely because IPv6 makes IPsec mandatory, IPv6 can not be more secure than IPv4. That was indeed the point of that slide. -- that aside, IPsec is a SHOULD (rather than a MUST) in the latest node-reqs-bis document [] For the end to end security, only the end systems requiring the security are required to deploy mechanisms for the security, which means it is not necessary to mandate all the end systems deploy some security protocol. Sorry, I couldn't parse this paragraph. Could you clarify this one? Thanks! Kind regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
I'm not a security guru, and will step aside instantly if someone with those credentials says I'm wrong. However, from my perspective, the assertion that IPv6 had any security properties that differed from IPv4 *at*all* has never made any sense. It is essentially a marketing claim, and - well, we all have marketing departments. From my perspective - this is what I am saying in the Smart Grid world and related places - security is a matter of reducing the probability and effectiveness of a set of threats to an acceptable level at an acceptable cost. In a network, it starts out with three questions: - why do you have access to my [local or network] bandwidth - why is your machine talking with my machine - why is your application talking with my application For the application, there are at least two more: - why should I listen to/act on/divulge to you what you say - How do I know that this message is really from you and is really what you said? In some cases, how will I know next week? There are also the questions of - obfuscation or encryption, at the application or network layers, - diagnostic tools such as intrusion management - attack management tools like uRPF or BGP filters Reasonable solutions for addressing the questions include (and are obviously not limited to) - IEEE 802.1X + EAP-TLS on a LAN, and a firewall on a network - IPsec AH or ESP-NULL - TLS and friends - Application-specific procedures like user-specific credentials - DKIM and W3C XML signatures plus - various encryption services include IPsec ESP, SSH, and so on - lots of proprietary tools for intrusion management - various operational tools for dealing with ddos etc IPsec was designed for IPv4 and IPv6; it is either a shim header (IPv4) or one of the extension headers (IPv6). Most IPv4 and IPv6 implementations I know of support it, and have for a long time. Yes, the Node Requirements document makes a statement about IPv6 implementations and IPsec that isn't made regarding IPsec/IPv4; as a practical matter, folks that have it implemented for one generally have it for the other. In the scope of things, wh does having one of out of the many needed tools make IPv6 different than IPv4, especially given that the indicated tool is present in both IPv4 and IPv6 implementations? Scratch-a-my-head. I don't see it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
On Tue, Oct 26, 2010 at 10:39 PM, Fred Baker f...@cisco.com wrote: snip In the scope of things, wh does having one of out of the many needed tools make IPv6 different than IPv4, especially given that the indicated tool is present in both IPv4 and IPv6 implementations? Scratch-a-my-head. I don't see it. I have a feeling the idea that IPv6 add something to security might be linked back to the IPsec focus real early on in the IPv6 era, like years and years ago. Why it happen or how, I don't really know. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [Full-disclosure] IPv6 security myths
Roger Jørgensen wrote: Sent: Tuesday, October 26, 2010 1:53 PM To: Fred Baker; IETF Discussion Subject: Re: [Full-disclosure] IPv6 security myths On Tue, Oct 26, 2010 at 10:39 PM, Fred Baker f...@cisco.com wrote: snip In the scope of things, wh does having one of out of the many needed tools make IPv6 different than IPv4, especially given that the indicated tool is present in both IPv4 and IPv6 implementations? Scratch-a-my-head. I don't see it. I have a feeling the idea that IPv6 add something to security might be linked back to the IPsec focus real early on in the IPv6 era, like years and years ago. Why it happen or how, I don't really know. How it happened? --- Ever heard of NAT? At the time IPsec through nat did not widely exist, and even implementations that figured out udp had the problem that the cert often included a 1918 address which didn't match the packet header source address. It is easy to forget context when bashing something after the fact... As Fred said there are many things that go into defining 'security'. Often people that are too focused on their little corner of the world put a box around the term 'security' to fit within their local context. People that want to do something outside that box are by definition 'breaking security'. Consider that there are many impossible-to-resolve situations like: End user considers 'security' to mean nobody except the recipient can see this Network admin tasked with Intellectual Property protection considers 'security' to mean I have to see everything to verify its content doesn't violate security policy You can't have both of those cases at the same time, yet both definitions of 'security' are valid. When people force-fit their local context on someone else's attempt to use the ambiguous term, misunderstanding and group-think bashing closely follow. Tony ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
Hi, Tony, I have a feeling the idea that IPv6 add something to security might be linked back to the IPsec focus real early on in the IPv6 era, like years and years ago. Why it happen or how, I don't really know. How it happened? --- Ever heard of NAT? At the time IPsec through nat did not widely exist, and even implementations that figured out udp had the problem that the cert often included a 1918 address which didn't match the packet header source address. It is easy to forget context when bashing something after the fact... Sorry, but I don't follow. If the problem with widespread deployment of IPsec was NAT traversal, why didn't we see widespread IPsec deployment (for the general case) e.g. once RFC 3948 was published? And: Do you expect IPsec deplyment to increase dramatically as IPv6 gets deployed? Thanks! Kind regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
Hi, Fred, I'm not a security guru, and will step aside instantly if someone with those credentials says I'm wrong. However, from my perspective, the assertion that IPv6 had any security properties that differed from IPv4 *at*all* has never made any sense. It is essentially a marketing claim, and - well, we all have marketing departments. The problem probably is that this sort of claim has been made in supposedly-technically-savvy forums. Many, if not most, (supposedly) technical reports on IPv6 security assert that IPv6 provides improved security as a result of * (where * is usually mandatory IPsec support, but may also be security not being an add-on, but rather carefully thought during the design of the protocol, etc.) These claims are very usual e.g. in IPv6 Task Forces circles/documents/papers/reports. (IIRC, there was one of such documents published by the North American IPv6 Task Force). The recent EU IPv6 security paper seems to assume that IPsec deployment will increase dramatically as a result of IPv6 deployment. And even parts of the recent NIST report on IPv6 secure deployment assumes improved security In the scope of things, wh does having one of out of the many needed tools make IPv6 different than IPv4, especially given that the indicated tool is present in both IPv4 and IPv6 implementations? Scratch-a-my-head. I don't see it. Nor do I ;-) Thanks! Kind regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
On Oct 25, 2010, at 5:46 AM, Masataka Ohta wrote: Sabahattin Gucukoglu wrote: In the interest of fair and balanced discussion. It is of course that, merely because IPv6 makes IPsec mandatory, IPv6 can not be more secure than IPv4. But, the real problem of IPsec is that it expected some PKI could have provided the end to end security. However, the real myth is that PKI depends on security of a breakable chain of CAs, which is not the end to end security. For the end to end security, only the end systems requiring the security are required to deploy mechanisms for the security, which means it is not necessary to mandate all the end systems deploy some security protocol. Masataka Ohta By the way, I don't buy the assertion that the PKI has to be global; if it did have to be global, I suspect one would have come into existence. If my system is supposed to talk with any system on the planet, then yes, my system's public key needs to be accessible to them and theirs to me, along with information that says what authentications I might have or they might have. The thing is - my system *isn't* supposed to talk with every system on the planet, and as a matter of fact most that want to initiate sessions with mine have no business doing so. So I don't need the keys of every system on the planet, and they don't need mine. Only the ones I want my system talking with. Consider the Smart Grid example in the appendix to http://datatracker.ietf.org/doc/draft-baker-ietf-core. The questions there include (a) what systems are authorized to communicate with systems in the home (HAN), and (b) what systems are authorized to communicate with systems in the Advanced Metering Infrastructure (AMI), which includes the Neighborhood Area Network (NAN) and related utility networks. It turns out that those are pretty closed environments - I don't want the neighbor kid playing with my light switches, and the utility has some ideas about who should be able to play with its infrastructure. The few places where we allow someone to cross that boundary we control pretty tightly. Some utilities want the ability to directly control circuits in the home, to manage water heaters, air conditioners, thermal masses, or other specific things. They are only authorized to do so if there is a supporting contract, and that often (today) implies a separate meter that they can turn on and turn off. Other utilities want to be able to send price signals, which get interpreted by an energy management system within my home that might do something similar, or might do something less draconian but equally effective. For example, if my thermostat has multiple temperature settings (the ones at my house have morning, day, evening, and night settings), I might have a policy that tells the thermostat to control to a less rigorous (cooler or warmer depending on the time of year, and as a result more likely to be off) setting when the price is high. Either way, there are two systems I want accessing my meter - my energy management system and the utility's collector. The meter needs only the certificates that will allow it to talk with those, and anything else is TMI. If someone isn't allowed to talk with me, there isn't a lot of value in being able to securely identify them. We can infer from the fact that I can't identify them that I'm not supposed to talk with them. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
Fred == Fred Baker f...@cisco.com writes: Fred I'm not a security guru, and will step aside instantly if Fred someone with those credentials says I'm wrong. However, from Fred my perspective, the assertion that IPv6 had any security Fred properties that differed from IPv4 *at*all* has never made any Fred sense. It is essentially a marketing claim, and - well, we all Fred have marketing departments. I think I am a security guru, and I agree with you 95%. The major *security* advantage of IPv6 is that it removes 90% of complexity of IPv4 networks that results from layers of NAT, and then series of port-forwards through them. Do you realize that a 30 year old IT professional likely has never been on the Internet? Seriously. They got a home router for their DSL connection in 1997 when they were 17... they have spent their entire adult life behind some kind of IPv4 NAT. I once spent some time with a few such young people, and I came to understand that they were profoundly confused about what home routers do--- they assumed that all *routers* everywhere on the Internet do NAT. After all, *CISCO* routers run the world, and CISCO owns Linksys... Therefore a 3% security advantage of IPv6 is that it requires that know-it-all young people and you-can't-teach-me-anything grey beards have to learn new things and therefore have a better chance that they will get correct information. The other 2% is that when you get what appears to be attack from 2607:f0b0:f:3::178 via some internal network (on the wrong side of your firewall), you have a way better chance of tracing it than if the attack comes from 10.10.10.178. That contractor PC with outgoing PPTP tunnel didn't mean to advertise your 10.10.10.0/24 network to my 10.10.10.0/24 network via OSPF, it just happened. The above will, I think, be a daily occurance in the world of SmartGrid for the first 10 years. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
On 10/26/2010 3:05 PM, Michael Richardson wrote: The major*security* advantage of IPv6 is that it removes 90% of complexity of IPv4 networks that results from layers of NAT, and then series of port-forwards through them. That's an operational hope, not a technical or operational fact. It is predicated on the belief that small address space is the only reason we have NATs. There's plenty of evidence for additional reasons which IPv6 does not eliminate. Ergo, your listed major security advantage is on extremely soft ground, possibly qualifying as quicksand... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
On Oct 26, 2010, at 14:18, Fernando Gont wrote: Sorry, but I don't follow. If the problem with widespread deployment of IPsec was NAT traversal, why didn't we see widespread IPsec deployment (for the general case) e.g. once RFC 3948 was published? RFC 3498 really only made a variant of tunnel-mode ESP traverse NAT by encapsulating it in UDP, and the result was predictable: widespread deployment of tunnel-mode ESP for VPN applications where the client is behind NAT and the access concentrator is at a globally routed and reachable address. We still don't have much transport IPsec ESP (much less AH) in the public IPv4 Internet, and the main reason is the ubiquitous deployment of IPv4/NAPT for address amplification purposes, especially at residential gateways. And: Do you expect IPsec deplyment to increase dramatically as IPv6 gets deployed? If you drop the need for NAPT at residential gateways, then I predict you will see a lot more IPsec on the public Internet. Put another way, if you're looking for an effective way to discourage the use of IPsec over IPv6, then find a way to force residential gateways to require IPv6/NAPT functions, e.g. to provide IPv6 address amplification. There are probably other ways-- *better* ways-- but that's the historically proven way of doing it. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
Fernando == Fernando Gont ferna...@gont.com.ar writes: How it happened? --- Ever heard of NAT? At the time IPsec through nat did not widely exist, and even implementations that figured out udp had the problem that the cert often included a 1918 address which didn't match the packet header source address. It is easy to forget context when bashing something after the fact... Fernando Sorry, but I don't follow. If the problem with widespread Fernando deployment of IPsec was NAT traversal, why didn't we see Fernando widespread IPsec deployment (for the general case) Fernando e.g. once RFC 3948 was published? (go read my RFC4322) Because: a) we didn't have a way to unique identify the end nodes therefore b) since everyone is 192.168.1.101, we couldn't put that into the certificates (whether X.509/pkix, SPKI or something like DNS IPSECKEY), we are left with trying to IPsec via transport mode, and it's fundamentally difficult to make IPsec+RFC3948+transport work if the IPsec is a bump-in-the-stack. If you want to know why forward names do not work, please read rfc4322. When the Freeswan project ran out of funding in Feb.2004, we were seriously looking at whether or not we could just run IPv6-over-IPv4UDP everywhere. 6to4 had just come out, and Teredo was being discussed, and the HIP people had some very interesting results doing exactly this. Fernando And: Do you expect IPsec deplyment to increase Fernando dramatically as IPv6 gets deployed? Partly. I also expect VPN use to get reduced, since 90% of VPNs are really just remote-access systems necessary due to NAT, not security. Most applications, due to lack of ubiquitous IPsec, are using TLS anyway, so why do things twice? (there are reasons, but for many applications, it's not important enough) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
On Tue, 26 Oct 2010, Michael Richardson wrote: Partly. I also expect VPN use to get reduced, since 90% of VPNs are really just remote-access systems necessary due to NAT, not security. In my experince, VPNs are used for secure connections between two private networks ... the existance of NAT is incidental to the objectives of the network owners. Firewalls, yes, NAT, n/a. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [Full-disclosure] IPv6 security myths
Fernando Gont wrote: IPsec is a SHOULD (rather than a MUST) in the latest node-reqs-bis document Too late, too little. [] For the end to end security, only the end systems requiring the security are required to deploy mechanisms for the security, which means it is not necessary to mandate all the end systems deploy some security protocol. Sorry, I couldn't parse this paragraph. Could you clarify this one? In general, applications determine which security mechanism to use. Configurable boxes can install IPsec when applications requiring IPsec is installed. Unconfigurable boxes with fixed applications may or may not have IPsec depending on preinstalled applications. So, IPsec, or any other security mechanism, should be purely optional. Note that security mechanisms, anyway, need configuration of passwords etc. BTW, IPsec was mandated in IPv6 with the discussion that ICMPv6, regarded as an application, could be secured by IPsec, which, of course, is untrue. People tend to think PKI works magically. Masataka Ohta PS Port restricted IPv4, including end to end NAT, is transparent to IPsec, as long as SPI can be regarded as port numbers. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
Michael, The major *security* advantage of IPv6 is that it removes 90% of complexity of IPv4 networks that results from layers of NAT, and then series of port-forwards through them. You seem to be assuming that there will not be middle-boxes with IPv6. -- NAT64, for example, doesn't seem to support that claim. And NAT66, allegedly one of the most required IPv6 features does not support your claim, either. Also, stateful firewalls (a la only allow return traffic) are not much different than NATs in terms of state -- although I agree that things get uglier with CGNs. Anyway: since we will be running both IPv4 and IPv6 for lots of years, the complexity of IPv6 adds to that of IPv4. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
Michael Richardson wrote: The major *security* advantage of IPv6 is that it removes 90% of complexity of IPv4 networks that results from layers of NAT, and then series of port-forwards through them. See page 13 of the slide of Gont stating: Ironically, NAT66 is one of the most frequently-asked IPv6 features As effective address space enhancement by port restricted IP keeps the end to end transparency for IPsec, there is no reason to have IPv6 only for the 10 times more complexity of mixed IPv4/6 networks connected by legacy NAT. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
Fred == Fred Baker f...@cisco.com writes: Fred By the way, I don't buy the assertion that the PKI has to be Fred global; if it did have to be global, I suspect one would have Fred come into existence. Quite a number of ideas and protocols have suffered because of the lack of such a thing. They haven't suffered so much as to cause such a thing to be created, but I do want to point to Microsoft AD and suggest that this system is pushing towards making such a system possible. (I'm not a fan. Having to run AD to participate in a global PKI is something I fear...) Fred If my system is supposed to talk with any system on the Fred planet, then yes, my system's public key needs to be Fred accessible to them and theirs to me, along with information Fred that says what authentications I might have or they might Fred have. The thing is - my system *isn't* supposed to talk with Fred every system on the planet, and as a matter of fact most that Fred want to initiate sessions with mine have no business doing Fred so. So I don't need the keys of every system on the planet, Fred and they don't need mine. Only the ones I want my system Fred talking with. I mostly agree, but: Fred Consider the Smart Grid example in the appendix to Fred http://datatracker.ietf.org/doc/draft-baker-ietf-core. The Fred questions there include (a) what systems are authorized to Fred communicate with systems in the home (HAN), and (b) what Fred systems are authorized to communicate with systems in the Fred Advanced Metering Infrastructure (AMI), which includes the Fred Neighborhood Area Network (NAN) and related utility Fred networks. It turns out that those are pretty closed My problem is that the union of all of the people/machines involves is essentially everyone. While nothing in my HAN needs to talk to your HAN in order for each of us to benefit from Smartgrid, the AMI/NAN has to communicate with both HAN, so the identities asserted inside each HAN have to be unique. (A CERT or new RR in IPv6 reverse DNS work work wonderfully. Who signs it, or whether self-signed is sufficient with return routing checks is an open question) Fred environments - I don't want the neighbor kid playing with my Fred light switches, and the utility has some ideas about who Fred should be able to play with its infrastructure. The few places Fred where we allow someone to cross that boundary we control Fred pretty tightly. Some utilities want the ability to directly Fred control circuits in the home, to manage water heaters, air Fred conditioners, thermal masses, or other specific things. They Fred are only authorized to do so if there is a supporting Fred contract, and that often (today) implies a separate meter that Fred they can turn on and turn off. Other utilities want to be able So, to support the utility doing this on a home-by-home basis, then we need the homes uniquely identified (argues for IPv6 rather than OID routing over NAT'ed IPv4). Does the utility need to trust the home (i.e. does the utility need certificates for the home entities)? Not if the utility can reach out to the home in an active way. Perhaps in the IPv4 NAT case where the utility has to be contacted (polled). Imagine that: security requirements are different if we assume IPv6 :-) Fred to send price signals, which get interpreted by an energy Fred management system within my home that might do something Fred similar, or might do something less draconian but equally Fred effective. For example, if my thermostat has multiple Fred temperature settings (the ones at my house have morning, day, Fred evening, and night settings), I might have a policy that tells Fred the thermostat to control to a less rigorous (cooler or warmer Fred depending on the time of year, and as a result more likely to Fred be off) setting when the price is high. Either way, there Fred are two systems I want accessing my meter - my energy Fred management system and the utility's collector. The meter needs Fred only the certificates that will allow it to talk with those, Fred and anything else is TMI. If I put two root PKI CAs into my thermostat, and you can put two different root CAs into your meter, that's okay. If either of those CAs are in common, then that entity has to coordinate identities. If one collapses the hierarchy and one just inserts self-signed certificates into the thermostat, most of the problems of coordination go away, but I don't think the utility is going to like the maintenance issue. Fred If someone isn't allowed to talk with me, there isn't a lot of Fred value in being able to securely identify them. We can infer Fred from the fact that I can't identify them that I'm not supposed Fred to talk with them. If you visit me as a house guest, your personal computing device is going to want to
Re: [Full-disclosure] IPv6 security myths
David == David Morris d...@xpasc.com writes: Partly. I also expect VPN use to get reduced, since 90% of VPNs are really just remote-access systems necessary due to NAT, not security. David In my experince, VPNs are used for secure connections between David two private networks ... the existance of NAT is incidental David to the objectives of the network owners. Firewalls, yes, NAT, David n/a. Of course, I'm not rejecting this use. That's the 10% that I didn't mention. If you take the pool of IPv4 speaking endpoints that have IPsec running, I'm claiming that 90% of those are doing some kind of remote-access situation. While you might argue the remaining 10% of site-to-site VPNs might overshadow the 90% in terms of backbone traffic, that wasn't my point. Further, about every third question the Freeswan/openswan support gets is basically: how do I run IPsec when both my gateways are behind NAPT? (and I want to use IKEv1 with main mode with PSK auth...) The answer is that you can't do it if your identity is ID_IPV4. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
Dave == Dave CROCKER d...@dcrocker.net writes: The major*security* advantage of IPv6 is that it removes 90% of complexity of IPv4 networks that results from layers of NAT, and then series of port-forwards through them. Dave That's an operational hope, not a technical or operational Dave fact. Dave It is predicated on the belief that small address space is the Dave only reason we have NATs. There's plenty of evidence for Dave additional reasons which IPv6 does not eliminate. Dave Ergo, your listed major security advantage is on extremely Dave soft ground, possibly qualifying as quicksand... NAT66, where the private address is a globally unique, and whois'able address is does not change the simplifications. (This is a reason I dislike ULA-R, and I've argued for a liberalized approach to allocations to non-connected networks over at arin-ppml) But, 90% of the situations where I see hopelessly complicated networks full of crazy NAPT4 are not at professional enterprises where they did it on purpose. It's at SOHO networks where NAPT4 routers are used to extend a connection for multiple things. For instance, a reason to create a new network zone is because we don't provide printers with decent access control lists (authorization), instead, we make them wide open and then throw WPA on the wireless so that it's secure, and then assume if you've authenticated, you are authorized to print. IPv6 would make that a new subnet, no additional layer of NAT, and do the authorization by IP address. (with SEND to secure the mapping!) From what I can see, most of the disasters of IPv4 I've seen are the result of semi-professionals applying what they learnt wiring up their home (and their mother-in-laws' house), and then applying the same thing elsewhere. So, if we get the home/residential experience right for IPv6, then I think we will clean up the worst situations I've seen. The enterprises which inflict pain on themselves with NAT44 and therefore NAT66, for security reasons will at least be in charge of their own fate. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
Michael, For instance, a reason to create a new network zone is because we don't provide printers with decent access control lists (authorization), instead, we make them wide open and then throw WPA on the wireless so that it's secure, and then assume if you've authenticated, you are authorized to print. IPv6 would make that a new subnet, no additional layer of NAT, and do the authorization by IP address. Huh? Why would one authorize access to a printer on a per-address basis? Why should every user on the same computer have the same access rights to the printer? -- This is probably a hint that, even if deployable, IPsec may not be want you need/want. (with SEND to secure the mapping!) And you argued against overly complex networks? Sigh (paraphrasing you) and then we throw IPsec and SEND so that it's secure, and then assume that if your IP address is authorized, the user at that IP address is authorized to print. Thanks, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: [Full-disclosure] IPv6 security myths
In the interest of fair and balanced discussion. Cheers, Sabahattin ---BeginMessage--- Folks, I thought you might enjoy the slides of a talk about IPv6 security I gave last week at LACNOG (http://www.lacnog.org). The slides are available at: http://www.gont.com.ar/talks/lacnog2010/fgont-lacnog2010-ipv6-security.pdf They are also available at the LACNOG 2010 web site (http://www.lacnog.org/en/meetings/lacnog-2010/agenda-lacnog-2010) Thanks! Kind regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ---End Message--- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fwd: [Full-disclosure] IPv6 security myths
Sabahattin Gucukoglu wrote: In the interest of fair and balanced discussion. It is of course that, merely because IPv6 makes IPsec mandatory, IPv6 can not be more secure than IPv4. But, the real problem of IPsec is that it expected some PKI could have provided the end to end security. However, the real myth is that PKI depends on security of a breakable chain of CAs, which is not the end to end security. For the end to end security, only the end systems requiring the security are required to deploy mechanisms for the security, which means it is not necessary to mandate all the end systems deploy some security protocol. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
