Subject: Fwd: [Full-disclosure] IPv6 security myths

From: Sabahattin Gucukoglu <[email-masked]>
Date: Mon, 25 Oct 2010 12:30:59 +0100

In the interest of fair and balanced discussion.

Cheers,
Sabahattin

Subject: [Full-disclosure] IPv6 security myths
From: Fernando Gont <[email-masked]>
To: [email-masked]
Cc: [email-masked], Fernando Gont <[email-masked]>
Date: Sun, 24 Oct 2010 18:33:28 -0300
List-Id: An unmoderated mailing list for the discussion of security issues <full-disclosure.lists.grok.org.uk>

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: [email-masked] || [email-masked]
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/

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 25 Oct 2010 21:46:31 +0900

> 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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Oct 2010 11:15:58 -0300

Hi, Masataka,

> 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

[....]
> deploy some security protocol.

Sorry, I couldn't parse this paragraph. Could you clarify this one?

Thanks!

Kind regards,

---

From: Fred Baker <[email-masked]>
Date: Tue, 26 Oct 2010 13:39:49 -0700

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.

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 26 Oct 2010 22:52:34 +0200

On Tue, Oct 26, 2010 at 10:39 PM, Fred Baker <[email-masked]> 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?
>

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           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 26 Oct 2010 14:09:58 -0700

Roger Jørgensen wrote:
> Sent: Tuesday, October 26, 2010 1:53 PM
> To: Fred Baker; IETF Discussion
> Subject: Re: [Full-disclosure] IPv6 security myths
> 

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Oct 2010 18:18:42 -0300

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,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Oct 2010 18:31:59 -0300

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?
> 

Nor do I ;-)

Thanks!

Kind regards,

---

From: Fred Baker <[email-masked]>
Date: Tue, 26 Oct 2010 14:50:45 -0700

> deploy some security protocol.

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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 2010 18:05:10 -0400

>>>>> "Fred" == Fred Baker <[email-masked]> 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[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 26 Oct 2010 15:23:17 -0700

On 10/26/2010 3:05 PM, Michael Richardson wrote:
> The major*security*  advantage of IPv6 is that it removes 90% of

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

---

From: james woodyatt <[email-masked]>
Date: Tue, 26 Oct 2010 15:24:03 -0700

> (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

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 <[email-masked]>
member of technical staff, communications engineering

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 2010 18:28:16 -0400

>>>>> "Fernando" == Fernando Gont <[email-masked]> 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)

---

From: David Morris <[email-masked]>
Date: Tue, 26 Oct 2010 15:37:39 -0700 (PDT)

> 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.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 27 Oct 2010 07:42:50 +0900

Fernando Gont wrote:

> IPsec is a

Too late, too little.

> 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.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Oct 2010 19:48:49 -0300

Michael,

> 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,

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 27 Oct 2010 07:50:40 +0900

> 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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 2010 18:51:46 -0400

>>>>> "Fred" == Fred Baker <[email-masked]> 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 reach out to my house system.  You won't be able to
communicate, as you indicate.  However, I want my house to accept and
store your certificate/identity such that I can now authorize you.
Again, does not require a global PKI if done right.  It's very
SPKI-like.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 2010 19:03:15 -0400

>>>>> "David" == David Morris <[email-masked]> 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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 26 Oct 2010 20:30:45 -0400

>>>>> "Dave" == Dave CROCKER <[email-masked]> writes:
    >> 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.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 27 Oct 2010 01:25:46 -0300

Michael,

> 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,

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Oct 2010 11:03:51 -0400

>> the authorization by IP address.

    Fernando> Huh? Why would one authorize access to a printer on a per-address basis?
    Fernando> Why should every user on the same computer have the same access rights
    Fernando> to the printer? -- This is probably a hint that, even if deployable,
    Fernando> IPsec may not be want you need/want.

Right now, everyone who knows the WPA2 key for the network can print.
I agree that the printer needs finer grained access controls.

IPsec, the specification, btw, has them, but they are not widely
implemented, and there has been no interest in the community towards any
kind of standard API for applications to be able to communicate with the
IPsec service about that.

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 27 Oct 2010 17:49:11 +0200

> 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 diffe…

Actually, the claim was made, and was correct at the time under assumptions that proved false.

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, we assumed (in 1994) that IPv6 rollouts would start around 1996-1997.  Given that, we didn't think that any vendors were going to bother adding IPsec to their v4 stacks.  If that had all come to pass, v6 would indeed have been more secure.  Even as late as 2000, I could still assert that v6 had some advantages; see http://www.cs.columbia.edu/~smb/talks/v6-security/index.htm

We all know what happened.  It's 2010, and deployment is finally starting in earnest.  Virtually v4 stacks have IPsec.  There's a a way to send IPsec through NATs (under certain circumstances).  And no one cares much about host-to-host IPsec, as opposed to host-to-gateway VPNs.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 28 Oct 2010 01:07:32 +0900

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

---

From: TJ <[email-masked]>
Date: Sat, 30 Oct 2010 23:12:05 -0400

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" <[email-masked]>
wrote:
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "Michel Py" <[email-masked]>
Date: Sat, 30 Oct 2010 20:28:30 -0700

> TJ [[email-masked]] wrote:

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.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 31 Oct 2010 13:00:58 +0900

> 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

---

From: Francis Dupont <[email-masked]>
Date: Sun, 31 Oct 2010 09:23:22 +0100

In your previous mail you wrote:

=> this is a bit unfair: VPNs are the natural model for IPsec use
(putting back an uniform I could talk about red and black :-).

Regards

[email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 31 Oct 2010 17:46:56 +0900

> (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

---

From: TJ <[email-masked]>
Date: Sun, 31 Oct 2010 08:56:44 -0400

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" <[email-masked]>

---

From: TJ <[email-masked]>
Date: Sun, 31 Oct 2010 09:00:01 -0400

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" <[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 31 Oct 2010 11:54:18 -0400

> 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

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

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 01 Nov 2010 13:12:25 +0900

Hadriel Kaplan wrote:

> 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