[ipv6hackers] IPv6 security presentation at Hack.lu 2011

Folks, We have uploaded the slides of the IPv6 Security talk I gave at
<http://www.si6networks.com/presentations/hacklu2011/fgont-hacklu2011-ipv6-security.pdf>
If there are any topics in the slides that that you think might
benefit from debate/discussion/brainstorming, please feel free to post
to the list.

Fernado,

Well done.

Here are a few immediate reactions.

The Brief overview on auto-configuration should mention RDNSS/DNSSL RA
options.

Security Implications of Transition/Co-existance Mechanism should also
mention Dual-Stack Lite (RFC6333) along with Port Control Protocol (PCP)
NAT-PMP Interworking Function.

---
In Key areas in which further work is needed:

The statement 'Pushing people to "Enable IPv6" point-and-click style is
simply insane' is deceptive. It is wrong to suggest _not_ enabling IPv6
in a network offers improved protections.

The statement 'Training is needed for engineers, technicians, security
personnel, etc., before the IPv6 network is running.' is also
deceptive. Unless extraordinary measures are taken which are also
likely to disable desired functionality, it would be wrong to suggest
IPv6 is not enabled in some fashion. IPv6 must be considered analogous
to that of a gun where security demands that it always be considered loaded.

Those who feel protected by an IPv4 NAT should also consider trade-offs
needed to sustain peak loads. Often shortcuts that minimize overhead
also allow exploits. We have seen several high profile companies and
agencies where IPv6 offers covert channels for breached data by some of
the newer bot-nets. In several cases, the IT staff were unaware of
there being any IPv6 connectivity. In this light, these two comments
are poorly considered to say the least.

"Always consider a network to have IPv6 connectivity and take steps to
security it." would be better advice.

Any NAT device within a network provides an easily exploited opportunity
for undetected MITM attacks. Only End-to-End security offers protection
from exploits related with ARP or ND+MLD where End-to-End security is
likely only possible with IPv6. This does not need to be IPsec.

In the further work needed section, perhaps a statement that RA resource
management flaws MUST still be corrected within affected hosts, such as
ignoring multiple headers or fragmentation to allow other OOB validation
methods whenever SEND is not available.

One might also add in further work section, the currently announced IPv6
size in conjunction with its exponential growth means use of source IP
addresses or prefixes alone are much less effective in attack mitigation
strategies. Just this prefix space is already more than 56,000 times
that of the entire IPv6 address space. Certificate based access should
be employed whenever possible might also be good advice.

-Doug

Fernando Gont

2011-09-22 06:48:18 UTC

Hi, Douglas,

Thanks so much for your feedback! Please find my comments inline..

Post by Douglas Otis
The Brief overview on auto-configuration should mention RDNSS/DNSSL RA
options.

Any particular reason for describing those? -- i.e., since it is a
one-hour presentation, it's mostly a high-level overview, that only gets
into some detail when needing to prove that something is more of a myth
than a "fact".

Post by Douglas Otis
---
The statement 'Pushing people to "Enable IPv6" point-and-click style is
simply insane' is deceptive.

While I might s/insane/incorrect/ (or the like), I do believe that
enabling a technology that one doesn't understand is a really bad idea.
-- If whoever enabled v6 needed "5-step recipe to enable v6" or the
like, then they probably should have been trained before enabling v6.

IMO, this applies to *any* technology, not just v6, and is mostly
orthogonal to how good or how bad are the security properties of that
technology.

If you don't know "good enough" how your network works, attackers will
probably do better.

Post by Douglas Otis
It is wrong to suggest _not_ enabling IPv6
in a network offers improved protections.

Well, I'd not say that it "provides improved protection", but rather
than "does not increase risk".

IPv6 (as any technology that you'd enable in addition to what you're
already using), will add more pieces to the puzzle, increase complexity,
and increase the number of potential vulnerabilities that could be
exploited.

Post by Douglas Otis
The statement 'Training is needed for engineers, technicians, security
personnel, etc., before the IPv6 network is running.' is also
deceptive. Unless extraordinary measures are taken which are also
likely to disable desired functionality, it would be wrong to suggest
IPv6 is not enabled in some fashion. IPv6 must be considered analogous
to that of a gun where security demands that it always be considered loaded.

If I don't know how to handle a gun, I'd probably wouldn't have one in
the first place. But if I *was* handled one, then I'd probably leave it
as quite as possible, rather than start loading bullets and playing with
the trigger, as if I knew what I was doing....

Post by Douglas Otis
Those who feel protected by an IPv4 NAT should also consider trade-offs
needed to sustain peak loads. Often shortcuts that minimize overhead
also allow exploits.

NATs do have some side-effect protections (albeit not bullet-proof,
since technologies such as Teredo can be leveraged to break that
assumption that "incoming connections are not allowed"). That said, I
fully agree that NATs introduce a "single point of failure" in the network.

Whether the pros outweigh (security-wise) the cons (or not) depends,
among other factors, where in the network the NAT box is. -- e.g.,
glearly a CGN has many more negative implications that a NAT at a home
router.

Post by Douglas Otis
We have seen several high profile companies and
agencies where IPv6 offers covert channels for breached data by some of
the newer bot-nets. In several cases, the IT staff were unaware of
there being any IPv6 connectivity. In this light, these two comments
are poorly considered to say the least.

The bottom-line is that you should make sure that your "assumptions" are
correct. -- e.g., if you're argument for not applying specific v6
technologies is that "my network is v4-only", you better make sure
that's the case.

Post by Douglas Otis
Any NAT device within a network provides an easily exploited opportunity
for undetected MITM attacks. Only End-to-End security offers protection
from exploits related with ARP or ND+MLD where End-to-End security is
likely only possible with IPv6. This does not need to be IPsec.

I cannot see why you argue that end-to-end security is only possible
with IPv6.

Post by Douglas Otis
In the further work needed section, perhaps a statement that RA resource
management flaws MUST still be corrected within affected hosts, such as
ignoring multiple headers or fragmentation to allow other OOB validation
methods whenever SEND is not available.

Yes. Actually, I wrote to I-Ds to make an RA-Guard and ND-monitoring
mitigations:

* <http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt>
* <http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-01.txt>

However, so far they are still "individual submissions", and that's why
I didn't mention this as a possible solution that could be applied to
solve these problems right now. But I agree that I should have
notes/insisted that this should be pursued.

Post by Douglas Otis
One might also add in further work section, the currently announced IPv6
size in conjunction with its exponential growth means use of source IP
addresses or prefixes alone are much less effective in attack mitigation
strategies.

When it comes to "filtering" as a mitigation for DoS, my take is that an
IPv6 /64 corresponds to what we currently do with a single IPv4 address.
Put another way, where in IPv4 you might be filtering a single IPv4
address or a small prefix, in IPv6 you'd be filtering at least a /64.

It would be worth adding, I agree.

Post by Douglas Otis
Just this prefix space is already more than 56,000 times
that of the entire IPv6 address space. Certificate based access should
be employed whenever possible might also be good advice.

Ip address-based authentication is already well-broken with IPv4. (e.g.,
I had mentioned that already when working on a sec assessment of v4
<http://www.gont.com.ar/papers/InternetProtocol.pdf>). So I'm not sure
anything changes in this respect when it comes to v6.

Thanks!

Best regards,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Eric Vyncke (evyncke)

2011-09-22 07:33:06 UTC

Fernando & Douglas,

Just to focus on the point whether enabling IPv6 is good or not... which is I think the major disagreement that I have with Fernando's points.

I would hate to do 'rogue access points' again but with IPv6. IPv6 is there, whether we like it or not, at the very heart of enterprises data centers thanks to Windows 2008 (there any IPS in the DC will not detect IPv6 attacks between Windows server -- assuming that one has been compromised)

Security people saying 'NO' are looking for trouble, they should say 'YES, BUT' :-)

My point is that indeed organizations should move to IPv6 but this must be planned with training, education, ... then deploying at least IPv6-aware IPS/Netflow/IPFIX/... and buying network devices that could deploy safely IPv6 (including layer-2 mitigation). CISO cannot be blinded.

Then, there are pretty good business reasons to deploy IPv6 in the coming months.

Or did I misread your point?

Regards

-éric

Post by Douglas Otis
It is wrong to suggest _not_ enabling IPv6
in a network offers improved protections.

Well, I'd not say that it "provides improved protection", but rather
than "does not increase risk".
IPv6 (as any technology that you'd enable in addition to what you're
already using), will add more pieces to the puzzle, increase complexity,
and increase the number of potential vulnerabilities that could be
exploited.

Fernando Gont

2011-09-22 08:44:55 UTC

Eric,

Post by Eric Vyncke (evyncke)
Just to focus on the point whether enabling IPv6 is good or not...
which is I think the major disagreement that I have with Fernando's
points.

Note that my presentation does not even touch on the subject on whether
there is good incentive to deploy IPv6 or not. It just focuses on
dismantling a number of myths regarding IPv6 security, and discussing a
number of issues that affect the security of emerging deployments.

Post by Eric Vyncke (evyncke)
Security people saying 'NO' are looking for trouble, they should say 'YES, BUT' :-)

Security people must discuss the security implications. Whether the
final answer is "YES" or "NOT" depends on a number of factors
(basically, if the the benefits you get are worth the increased risk),
and are not a "one size fits all".

For example, there are reasons for which, for example, a defense network
might not want to deploy IPv6.

Post by Eric Vyncke (evyncke)
My point is that indeed organizations should move to IPv6 but this
must be planned with training, education, ...

My point was, essentially, that if you decide to deploy IPv6, this
should be planned with proper education, and consideration of the
security implications.

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Douglas Otis

2011-09-22 23:55:40 UTC

On 9/21/11 11:48 PM, Fernando Gont wrote:
Hi Fernando,

Post by Fernando Gont
Hi, Douglas,
Thanks so much for your feedback! Please find my comments inline..

Post by Douglas Otis
The Brief overview on auto-configuration should mention RDNSS/DNSSL RA
options.

Yes. DHCP is NOT required by IPv6 to support DNS. This impacts
security that depends upon DHCP snooping and should be mentioned.

Many expect a transition to IPv6 will not occur soon. However support
issues related with 6to4 caused a rethink by ISPs. The less painful
option is Dual-Stack Lite where ISPs deploy native IPv6 with centrally
controlled LSN where customers might share IPv4 addresses. This
increases a desire for IPv6 connectivity for improved security and freedom.

Post by Douglas Otis
---
The statement 'Pushing people to "Enable IPv6" point-and-click style is
simply insane' is deceptive.

While I might s/insane/incorrect/ (or the like), I do believe that
enabling a technology that one doesn't understand is a really bad idea.

Even the assumption IPv6 is not enabled is a flawed concept. In
addition it would be appropriate to assume there WILL be an IPv6
firewall when IPv6 is enabled. Alternatively, it would be wrong to
assume any effective IPv6 firewall exists otherwise. Perhaps you could
replace "disable IPv6" with "disable Protocol 41" instead. :^)

Post by Fernando Gont
-- If whoever enabled v6 needed "5-step recipe to enable v6" or the
like, then they probably should have been trained before enabling v6.

Again, the message should be that IPv6 _already_ exits within their
networks. Enabling IPv6 on the LAN permits better monitoring and
suppresses more problematic fallback strategies. The message should be
there is a need to monitoring this traffic NOW! Not enabling IPv6 on
the LAN only offers a false sense of security.

Post by Fernando Gont
IMO, this applies to *any* technology, not just v6, and is mostly
orthogonal to how good or how bad are the security properties of that
technology.
If you don't know "good enough" how your network works, attackers will
probably do better.

Exactly. Any compromised system within a LAN can easily set up IPv6
connectivity, specifically because a lax approach was taken where not
enabling IPv6 was seen as offering improved security. :^(

Post by Douglas Otis
It is wrong to suggest _not_ enabling IPv6
in a network offers improved protections.

Well, I'd not say that it "provides improved protection", but rather
than "does not increase risk".

Disagree. This view increases risks by offering the false concept that
relative inaction is better. By suggesting a NEED to enable IPv6 within
the LAN raises attention to the fact that IPv6 is already present and
the related risks MUST be mitigated or at least monitored. These risks
do not go away because IPv6 is not enabled. Instead these risks become
more difficult to monitor and the lack of monitoring gives malefactors a
field day. As it is now, everyday is a field day. :^(

Post by Fernando Gont
IPv6 (as any technology that you'd enable in addition to what you're
already using), will add more pieces to the puzzle, increase complexity,
and increase the number of potential vulnerabilities that could be
exploited.

Complexity could be reduced by RAs announcing routes and RDNSS where any
AAAA records in DNS are filtered and any other IPv6 traffic is
black-holed. Even that effort will not stop malefactors from using
their own covert name services and IPv6 networks within a LAN where IT
"thought" IPv6 was disabled.

Internet connectivity IS a loaded gun. Inaction after "disabling IPv6"
is like leaving the safety off in the presence of children. Disabling
IPv6 on the LAN offers NO protection nor does it make maintaining
security easier. The natural reaction of the OS or application is to
then seek alternatives.

Post by Douglas Otis
Those who feel protected by an IPv4 NAT should also consider trade-offs
needed to sustain peak loads. Often shortcuts that minimize overhead
also allow exploits.

Please overcome misconceptions regarding NATs and IPv6. Whether IPv6 or
IPv4 is used, a LAN is vulnerable without SeND. Middle Boxes such as
NATs remove many protections otherwise possible. The LAN is vulnerable
whether through ARP spoofing, spanning tree or NAT table corruption,
etc. With RFC793 simultaneous-open handshakes, a Sneak Ack Attack can
reverse the logical direction of connection setups. Even symmetric NAT
restrictions on undefined endpoints can be defeated by an unprivileged
compromised system through the use of broadcast MACs or techniques that
take advantage of exceptions that permit diagnostics.

See:
http://www.cs.columbia.edu/~smb/talks/arp-attack.pdf
http://nmap.org/misc/split-handshake.pdf
http://samy.pl/pwnat/

Often applications don't notice when an SSL certificate fails to match
against a domain. Even with SSL, Middle Boxes offer easy MitM
exploits. It is absurd to describe NATs as offering improved
protection. Practices that depend on NAT "security" invite prone
systems that do more harm. IMHO, it is easier to firewall IPv6 than
deal with IPv4 related nonsense such as keep-alives, dynamic
translations, port mapping, etc.

Post by Fernando Gont
Whether the pros outweigh (security-wise) the cons (or not) depends,
among other factors, where in the network the NAT box is. -- e.g.,
glearly a CGN has many more negative implications that a NAT at a home
router.

There are many compromised CPE routers. An ISP's LSN are not likely to
be any worse.

Assuring an assumption of "IPv4 Only" requires a sizable effort that
will prevent improved security from then being employed. :^(

I cannot see why you argue that end-to-end security is only possible
with IPv6.

It is possible to deploy SeND at Switches and routers without support of
the hosts. In this fashion, a far greater portion of the path can be
controlled where common LAN exploits can be avoided or detected.

Yes. Actually, I wrote to I-Ds to make an RA-Guard and ND-monitoring
*<http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt>
*<http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-01.txt>
However, so far they are still "individual submissions", and that's why
I didn't mention this as a possible solution that could be applied to
solve these problems right now. But I agree that I should have
notes/insisted that this should be pursued.

The table size needed for such a strategy will likely increase in by a
factor of about 340,000 over what is used for IPv4 when only IPv6
prefixes are captured. Of course, this short-cut will disable entire
networks whenever someone forgets their password and tries too many
times. Not a practical defense strategy in many cases. IP address
related security must be replaced by certificates that can establish
white-listed address space for short durations. Perhaps wide spread
deployment of DANE with dynamic DNS updates is where this needs to
evolve. Without something like this, keeping up with a geometrically
increasing attack surface seems doubtful.

Some now hope in a new repute WG to base reputation on IP address
authorizations and message signatures that exclude who sent the message
and its intended recipient! This is another reason for mentioning
Dual-Stack Lite to raise security considerations that are related to
both the evolving IPv6 AND IPv4 address space.

And thank you for your valuable efforts.

-Doug

Jim Small

2011-09-23 01:10:09 UTC

This is a great discussion. My big wish though is to talk about actionable items:

Regarding RDNSS - I thought this was essentially unsupported but I was pleasantly surprised to find out that many of the latest O/S versions do support it:
http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems
Notably OS X 10.7 includes support for this. Unfortunately it is still lacking in Windows but I think it is likely this will be fixed in Windows 8.

Post by Douglas Otis
Many expect a transition to IPv6 will not occur soon.

[JRS>] This is not exactly security related but I have done much research and speaking on this topic. In fact the largest broadband provider in the US (Comcast) will have *completed* their IPv6 rollout sometime next year. The 2nd largest cable company (Time Warner) is close behind. There is similar activity in Europe. Most of the major cellular carriers are rolling out IPv6 next year. Those who think that IPv6 is years away and in for a rude awakening shortly.

Post by Douglas Otis
It is possible to deploy SeND (...)

I guess I am perplexed by the discussions of SeND. It's a great protocol but it isn't implemented (at least in the mainline kernel) of any O/S. So it's completely theoretical. Please forgive me for being a technician but I would much prefer to focus on technologies which we can actually implement or which have a chance of being adopted. Microsoft and Apple have no interest in this and it hasn't made it into the Linux kernel so to me any conversation about SeND seems pointless. Am I missing the boat here?
[JRS>] Thank you Fernando for all your hard work in pushing for solutions to the existing problems.

--Jim

Leinweber, James

2011-09-23 04:48:47 UTC

We have uploaded the slides ...

Nice presentation; thanks for sharing.

Many expect a transition to IPv6 will not occur soon.

And many would be wrong, though it's been 13 years in the making.
Rapid growth of the internet in the face of native v6 being better +
faster + cheaper than carrier NAT is going to change that. IPv4
exhaustion matters.

On the IPSEC front, it might be worth pointing out that the
interesting security issues such as rampant endpoint insecurity
regardless of network protocol, immature v6 protocol stacks, and lack
of v6 feature parity have nothing to do with IPSEC. Meanwhile, if
those living in a Windows monoculture who find "direct access" VPN's
helpful might actually lead to a handful of IPSEC deployments.

In addition to the point that dual-stack hosts create v6
vulnerabilities in supposedly v4-only networks, it might
be worth emphasizing a few more of the implications of
living in a dual-stack world, such as:

* Carrier-grade / Large scale NAT devices mean that v4 forensics
has to change: you can't track an attacker based on IP address
unless you also know the timestamp, protocol, and port numbers.

* v6-mostly web sites aren't yet usually v6-only, so you need dual-
stacked packet traces to see what clients actually pulled down.

* The plethora of protocols and addresses (v4, v6; link-scope,
global-scope; unicast, multicast) in simultaneous use means
network forensics will have to be based on port-snooping.

... RDNSS ... likely ... will be ... in WIndows 8

Anyone willing to bet against "happy eyeballs" (race parallel v6 and
v4, deliver the winner) also being in windows 8, given that Google
Chrome, Firefox, and OS-X 10.7 already have it? I've been pleasantly
surprised by how fast it's deploying.

... Those who think that IPv6 is years away [are] in for a rude
awakening shortly.

Amen, brother.

Add AT&T U-verse customers to the list of those about to get IPv6 in
the US, too. World IPv6 day in France saw 3% v6 traffic on the
backbone; French ISP's have been earlier than most in completing v6
rollouts. Sadly, my own ISP is dragging its feet; happily, my
employer already offers a dual-stacked VPN service.

As near as I can tell, if you have Asian customers, Asian supply
chains, mobile customers, or you are an IT supplier to major
governments, you should already have IPv6 rolled out. Assuming
current growth rates, about 15% of the internet is likely to be v6-
only in 2013. Consumer preference is liable to flip as soon as
December 2014, if some hot v6-only electronic toy comes out of a
pacific rim country in time for the holiday shopping season. 99% of
IP traffic could be v6 in 2017; Cisco reported that at Interop and
Cisco Live conferences this summer with a dual-stack native
environment and the current client mix 60% of traffic flipped to v6.
IPv4 backbone routing is likely to turn off in 2020 - and this is
already predicted in AT&T's roadmap. There was no economic incentive
to start rolling out v6, but there is a very strong incentive to stop
routing v4. What does going v6-only save you on DFZ router load,
maybe 50% on memory and 95% on CPU? We're seeing about a 7:1 ratio
between v4 routes and v6 routes currently out of the minority of
dual-stacked autonomous systems, right?

Meanwhile, transition plan A (dual stack "heavy") foundered on lack
of IPv4 address space, and plan B (dual stack lite) seems to be
ignored in favor of plan C: v6-only with NAT64/DNS64 converters to
the legacy v4 internet. Plan C is where the University of Wisconsin
expects to end up once it runs out of v4, probably in 2013. I think
NAT64 is winning because for cell phones it's cheaper to be mono-
stack than dual stack, and for ISP's NAT64 keeps less state than
NAT44, and so scales better. Phone companies and ISP's won't care
that v6-only customers have lousy experiences at v4-only web sites;
all the *big* sites in the US like google, bing, xbox, yahoo, facebook,
cnn,
youtube, netflix, etc. are already dual-stacked, or nearly ready.
Most peer to peer stuff clients and some gaming clients are already
dual-stacked. I know companies with advanced v6 rollout plans who
confidently expect that being early movers is about to yield them
competitive advantages.

I figure the dual-internet interregnum (the period where some people
don't have v4 and others don't have v6) runs 2009-2015. Even if the
last v4 device isn't likely to disappear until 2036 or so, in 2016
pretty much everyone who wants v6 should be able to have it.

The analogy I'm using to explain v4 -> v6 to end users in the US is
that it's like the transition from analog TV to digital TV: new gear
(broadband modems, wifi routers) all around to get mostly the same
content. Given the narrow product range and immaturity of
implementations, especially for DSL modems, I'm telling my fellow
Americans not to replace such gear till 2013, unless they like to
be on the bleeding edge.

v4 and v6 are both packet switched networks with best effort delivery
and next hop routing, so the threat models are basically identical.
The key security differences seem to me to be in areas like:

1) Big v6 address space means reputation lists will have to based
on blacklisting prefixes or whitelisting hosts; merely
blacklisting hosts is not going to cut it. So don't v6-enable
your mail server yet (do enable DNS and Web, obviously).

2) Extend your wired layer 2/3 defenses beyond DHCPv4 spoof
prevention to DHCPv6 and RA spoof prevention. RA's existed in
ICMPv4, but no one ever used them. On Cisco switches this week I
think I like parallel v4 and v6 ACL's on the ports for this.
What are other people using?

3) Block tunnels at your firewalls. If you have native v6 you
don't want them, and if you don't have v6 you probably aren't
ready to cope with them. In any case your network monitoring
probably can't inspect tunnels effectively, even if your
security infrastructure is dual stacked - which it should
already be. Forbidding protocol 41 and port 3544/udp is a very
good start on this.

-- Jim Leinweber
State Laboratory of Hygiene, University of Wisconsin - Madison
<***@slh.wisc.edu> phone +1 608 221 6281
PGP fp: D573 AF7D F484 EE2A F0B6 B7DB A870 7518 F87D A0D1

Jim Small

2011-09-23 18:23:49 UTC

James,

On the IPSEC front, it might be worth pointing out that the
interesting security issues such as rampant endpoint insecurity
regardless of network protocol, immature v6 protocol stacks, and lack
of v6 feature parity have nothing to do with IPSEC.
[JRS>] The problem I see with IPsec, especially remote access or "endpoint" IPsec is key management/distribution. PKI is sufficiently difficult to scare off many. Furthermore since it is poorly understood many think the sky is falling after the Dutch CA was compromised, apparently few understand the idea of revocation - but that's another story. Outside of PKI, I don't know of any great way to distribute and manage keys. This is what seems to limit its usefulness. There are actually some other problems yet to be solved but this seems the biggest.

Meanwhile, if those living in a Windows monoculture who find "direct access" VPN's
helpful might actually lead to a handful of IPSEC deployments.
[JRS>] What I find interesting about DirectAccess is that it requires IPv6. I have spoken with many who insist it doesn't only to discover they are running 6to4 at the edge and ISATAP internally, but that's not IPv6 right? :-)

Meanwhile, transition plan A (dual stack "heavy") foundered on lack
of IPv4 address space,
[JRS>] I think for enterprises and most organizations dual stack will be the approach, but I don't disagree with your comments.

and plan B (dual stack lite) seems to be
[JRS>] I think some carriers are doing this. This one is less clear to me, I think we'll see a lot more detail on the underlying infrastructure next year.

ignored in favor of plan C: v6-only with NAT64/DNS64 converters to
the legacy v4 internet. Plan C is where the University of Wisconsin
expects to end up once it runs out of v4, probably in 2013.
[JRS>] NAT64 is great for http and applications that don't require "fixups." However, for anything like FTP/SIP/H.323/RTSP/etc... it won't work or will require the NAT64 vendor to develop fixups. It's like we're back in the mid to late Ninetys with NAT44.

I think NAT64 is winning because for cell phones it's cheaper to be mono-
stack than dual stack, and for ISP's NAT64 keeps less state than
NAT44, and so scales better.
[JRS>] Agreed - T-Mobile is going this way and for cellular/mobile providers it makes perfect sense.

Phone companies and ISP's won't care that v6-only customers have lousy experiences at v4-only web sites;
all the *big* sites in the US like google, bing, xbox, yahoo, facebook, cnn,
youtube, netflix, etc. are already dual-stacked, or nearly ready.
[JRS>] By phone companies I'm assuming you mean DSL providers? I guess in this space I'm not sure but this sounds like a reasonable theory.

Most peer to peer stuff clients and some gaming clients are already
dual-stacked. I know companies with advanced v6 rollout plans who
confidently expect that being early movers is about to yield them
competitive advantages.
[JRS>] It's refreshing to hear that some really get it.

I figure the dual-internet interregnum (the period where some people
don't have v4 and others don't have v6) runs 2009-2015. Even if the
last v4 device isn't likely to disappear until 2036 or so, in 2016
pretty much everyone who wants v6 should be able to have it.
[JRS>] I guess the first big question is when does IPv4 get retired from the Internet. Conservative estimates are 2020. Mr. Huston would predict earlier and he has some compelling information. Since it will start to seriously ramp up next year, perhaps 2017???

The analogy I'm using to explain v4 -> v6 to end users in the US is
that it's like the transition from analog TV to digital TV: new gear
(broadband modems, wifi routers) all around to get mostly the same
content. Given the narrow product range and immaturity of
implementations, especially for DSL modems, I'm telling my fellow
Americans not to replace such gear till 2013, unless they like to
be on the bleeding edge.
[JRS>] Agreed, consumer CPEs are still an issue.

v4 and v6 are both packet switched networks with best effort delivery
and next hop routing, so the threat models are basically identical.
The key security differences seem to me to be in areas like:

1) Big v6 address space means reputation lists will have to based
on blacklisting prefixes or whitelisting hosts; merely
blacklisting hosts is not going to cut it. So don't v6-enable
your mail server yet (do enable DNS and Web, obviously).
[JRS>] This one is tricky - I'm not sure blacklisting will work. I'm not sure whitelisting is scalable, from what I have seen it seems to only work in tightly controlled environments which are typically not too large.

2) Extend your wired layer 2/3 defenses beyond DHCPv4 spoof
prevention to DHCPv6 and RA spoof prevention. RA's existed in
ICMPv4, but no one ever used them. On Cisco switches this week I
think I like parallel v4 and v6 ACL's on the ports for this.
What are other people using?
[JRS>] I know DHCPv6 snooping is coming. Fernando has some great papers explaining the shortcomings of RA guard - hopefully this will be fixed to deal with fragmentation/extension headers. I believe the ACLs can be bypassed by fragmentation - again, Fernando's papers explain this is excellent detail.

3) Block tunnels at your firewalls. If you have native v6 you
don't want them, and if you don't have v6 you probably aren't
ready to cope with them. In any case your network monitoring
probably can't inspect tunnels effectively, even if your
security infrastructure is dual stacked - which it should
already be. Forbidding protocol 41 and port 3544/udp is a very
good start on this.
[JRS>] Agreed but many of these are dynamic so you'll need some kind of IPS/DPI to deal with dynamic tunnels.

I especially like your statistics on IPv6 ramp up on the Internet - possible to share how you developed those?
--Jim

Cameron Byrne

2011-09-23 19:29:30 UTC

Post by Jim Small
James,
On the IPSEC front, it might be worth pointing out that the
interesting security issues such as rampant endpoint insecurity
regardless of network protocol, immature v6 protocol stacks, and lack
of v6 feature parity have nothing to do with IPSEC.
[JRS>] The problem I see with IPsec, especially remote access or

"endpoint" IPsec is key management/distribution. PKI is sufficiently
difficult to scare off many. Furthermore since it is poorly understood many
think the sky is falling after the Dutch CA was compromised, apparently few
understand the idea of revocation - but that's another story. Outside of
PKI, I don't know of any great way to distribute and manage keys. This is
what seems to limit its usefulness. There are actually some other problems
yet to be solved but this seems the biggest.

Post by Jim Small
Meanwhile, if those living in a Windows monoculture who find "direct access" VPN's
helpful might actually lead to a handful of IPSEC deployments.
[JRS>] What I find interesting about DirectAccess is that it requires

IPv6. I have spoken with many who insist it doesn't only to discover they
are running 6to4 at the edge and ISATAP internally, but that's not IPv6
right? :-)

Post by Jim Small
Meanwhile, transition plan A (dual stack "heavy") foundered on lack
of IPv4 address space,
[JRS>] I think for enterprises and most organizations dual stack will be

the approach, but I don't disagree with your comments.

Post by Jim Small
and plan B (dual stack lite) seems to be
[JRS>] I think some carriers are doing this. This one is less clear to

me, I think we'll see a lot more detail on the underlying infrastructure
next year.

Post by Jim Small
ignored in favor of plan C: v6-only with NAT64/DNS64 converters to
the legacy v4 internet. Plan C is where the University of Wisconsin
expects to end up once it runs out of v4, probably in 2013.
[JRS>] NAT64 is great for http and applications that don't require

"fixups." However, for anything like FTP/SIP/H.323/RTSP/etc... it won't
work or will require the NAT64 vendor to develop fixups. It's like we're
back in the mid to late Ninetys with NAT44.
I have not had any troubles in this area. I asked my nat64 vendor to
support ftp and rtsp and they delivered the ALGs, just like those protocols
work on nat44. Ymmv.

As was noted before, native ipv6 benefits everyone: user, isp, content, p2p
....

Cb

Post by Jim Small
I think NAT64 is winning because for cell phones it's cheaper to be mono-
stack than dual stack, and for ISP's NAT64 keeps less state than
NAT44, and so scales better.
[JRS>] Agreed - T-Mobile is going this way and for cellular/mobile

providers it makes perfect sense.

Post by Jim Small
Phone companies and ISP's won't care that v6-only customers have lousy

experiences at v4-only web sites;

Post by Jim Small
all the *big* sites in the US like google, bing, xbox, yahoo, facebook, cnn,
youtube, netflix, etc. are already dual-stacked, or nearly ready.
[JRS>] By phone companies I'm assuming you mean DSL providers? I guess in

this space I'm not sure but this sounds like a reasonable theory.

Post by Jim Small
Most peer to peer stuff clients and some gaming clients are already
dual-stacked. I know companies with advanced v6 rollout plans who
confidently expect that being early movers is about to yield them
competitive advantages.
[JRS>] It's refreshing to hear that some really get it.
I figure the dual-internet interregnum (the period where some people
don't have v4 and others don't have v6) runs 2009-2015. Even if the
last v4 device isn't likely to disappear until 2036 or so, in 2016
pretty much everyone who wants v6 should be able to have it.
[JRS>] I guess the first big question is when does IPv4 get retired from

the Internet. Conservative estimates are 2020. Mr. Huston would predict
earlier and he has some compelling information. Since it will start to
seriously ramp up next year, perhaps 2017???

Post by Jim Small
The analogy I'm using to explain v4 -> v6 to end users in the US is
that it's like the transition from analog TV to digital TV: new gear
(broadband modems, wifi routers) all around to get mostly the same
content. Given the narrow product range and immaturity of
implementations, especially for DSL modems, I'm telling my fellow
Americans not to replace such gear till 2013, unless they like to
be on the bleeding edge.
[JRS>] Agreed, consumer CPEs are still an issue.
v4 and v6 are both packet switched networks with best effort delivery
and next hop routing, so the threat models are basically identical.
1) Big v6 address space means reputation lists will have to based
on blacklisting prefixes or whitelisting hosts; merely
blacklisting hosts is not going to cut it. So don't v6-enable
your mail server yet (do enable DNS and Web, obviously).
[JRS>] This one is tricky - I'm not sure blacklisting will work. I'm not

sure whitelisting is scalable, from what I have seen it seems to only work
in tightly controlled environments which are typically not too large.

Post by Jim Small
2) Extend your wired layer 2/3 defenses beyond DHCPv4 spoof
prevention to DHCPv6 and RA spoof prevention. RA's existed in
ICMPv4, but no one ever used them. On Cisco switches this week I
think I like parallel v4 and v6 ACL's on the ports for this.
What are other people using?
[JRS>] I know DHCPv6 snooping is coming. Fernando has some great papers

explaining the shortcomings of RA guard - hopefully this will be fixed to
deal with fragmentation/extension headers. I believe the ACLs can be
bypassed by fragmentation - again, Fernando's papers explain this is
excellent detail.

Post by Jim Small
3) Block tunnels at your firewalls. If you have native v6 you
don't want them, and if you don't have v6 you probably aren't
ready to cope with them. In any case your network monitoring
probably can't inspect tunnels effectively, even if your
security infrastructure is dual stacked - which it should
already be. Forbidding protocol 41 and port 3544/udp is a very
good start on this.
[JRS>] Agreed but many of these are dynamic so you'll need some kind of

IPS/DPI to deal with dynamic tunnels.

Post by Jim Small
I especially like your statistics on IPv6 ramp up on the Internet -

possible to share how you developed those?

Post by Jim Small
--Jim
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Eric Vyncke (evyncke)

2011-09-26 12:53:22 UTC

Regarding 'happy eyeballs', I heard at the last IETF meeting from Microsoft mouth in a public WG that next IE (perhaps even 9.0 -- not sure) will implement 'happy eyeballs'

Implementing happy eyeballs in the OS has sense only when applications use API based on FQDN and not IP addresses. Mac OS/X applications often do not use socket API hence it is efficient for Mac OS/X to implement happy eyeballs in the OS, less sure about Windows

-éric

Post by Jim Small
-----Original Message-----
Sent: vendredi 23 septembre 2011 06:49

... RDNSS ... likely ... will be ... in WIndows 8

Erik Kline

2011-09-27 09:25:15 UTC

Post by Douglas Otis
Many expect a transition to IPv6 will not occur soon.

[JRS>] This is not exactly security related but I have done much research
and speaking on this topic. In fact the largest broadband provider in the
US (Comcast) will have *completed* their IPv6 rollout sometime next year.
The 2nd largest cable company (Time Warner) is close behind. There is
similar activity in Europe. Most of the major cellular carriers are rolling
out IPv6 next year. Those who think that IPv6 is years away and in for a
rude awakening shortly.

Indeed.

Jim Small

2011-09-27 19:47:30 UTC

Post by Erik Kline

Post by Douglas Otis
Many expect a transition to IPv6 will not occur soon.

[JRS>] This is not exactly security related but I have done much research
and speaking on this topic. In fact the largest broadband provider in the
US (Comcast) will have *completed* their IPv6 rollout sometime next year.
The 2nd largest cable company (Time Warner) is close behind. There is
similar activity in Europe. Most of the major cellular carriers are rolling
out IPv6 next year. Those who think that IPv6 is years away and in for a
rude awakening shortly.

Indeed.

Fernando Gont

2011-09-25 08:03:09 UTC

Hi, Doug,

Post by Douglas Otis
The Brief overview on auto-configuration should mention RDNSS/DNSSL RA
options.

Yes. DHCP is NOT required by IPv6 to support DNS. This impacts
security that depends upon DHCP snooping and should be mentioned.

NOt sure what you mean. In my presentation, DHCPv6 and SLAAC are mostly
described as *alternative* autoconf mechanisms. If I were to desdcribe
RDNSS, I'd also have to describe PI option, etc... and the slides don't
get into that level of detail.

Post by Douglas Otis
Many expect a transition to IPv6 will not occur soon. However support
issues related with 6to4 caused a rethink by ISPs. The less painful
option is Dual-Stack Lite where ISPs deploy native IPv6 with centrally
controlled LSN where customers might share IPv4 addresses. This
increases a desire for IPv6 connectivity for improved security and freedom.

Can you point out where this "increased security" comes from?

Post by Douglas Otis
The statement 'Pushing people to "Enable IPv6" point-and-click style is
simply insane' is deceptive.

While I might s/insane/incorrect/ (or the like), I do believe that
enabling a technology that one doesn't understand is a really bad idea.

Even the assumption IPv6 is not enabled is a flawed concept.

Sloppy wording: I should have said "deploy IPv6" rather than "enable IPv6".

Post by Douglas Otis
In
addition it would be appropriate to assume there WILL be an IPv6
firewall when IPv6 is enabled. Alternatively, it would be wrong to
assume any effective IPv6 firewall exists otherwise. Perhaps you could
replace "disable IPv6" with "disable Protocol 41" instead. :^)

"Disable proto 41" sounds good for referring to packets being filtered
at a firewall. However, other (not mutually exclusive) options are
avialable, such as disabling v6 suppport at the OS.

Post by Fernando Gont
-- If whoever enabled v6 needed "5-step recipe to enable v6" or the
like, then they probably should have been trained before enabling v6.

Again, the message should be that IPv6 _already_ exits within their
networks.

Agreed. This is is noted in several slides. e.g., the first few ones,
and the "IPv6 security implications on IPv4 networks".

Post by Douglas Otis
Enabling IPv6 on the LAN permits better monitoring and
suppresses more problematic fallback strategies.

It also enables pontential vulnerabilities. See the latest (?)
remotely-explotaible vulnerability in OpenBSD dated 2008 or so.

Post by Fernando Gont
If you don't know "good enough" how your network works, attackers will
probably do better.

Exactly. Any compromised system within a LAN can easily set up IPv6
connectivity, specifically because a lax approach was taken where not
enabling IPv6 was seen as offering improved security. :^(

If you disable IPv6 in the sense of removing support for it, that attack
is not possible.

Post by Douglas Otis
It is wrong to suggest _not_ enabling IPv6
in a network offers improved protections.

Well, I'd not say that it "provides improved protection", but rather
than "does not increase risk".

Disagree. This view increases risks by offering the false concept that
relative inaction is better.

Nobody said that. Please look at the slides. On the contrary, I'd argue
that *something* should be done about it.

Post by Douglas Otis
By suggesting a NEED to enable IPv6 within
the LAN raises attention to the fact that IPv6 is already present and
the related risks MUST be mitigated or at least monitored.

I wouldn't necessarily suggest "enabling IPv6". If we blindly advise
organizations to enable IPv6, and they get hacked as a result of that
(see the OpenBSD vulnerability above), then we'd have done a
(security-wise) very poor consulting work.

First of all comes an assessment of what the organization would gain
from enabling IPv6 (along with considering possible alternatives).
Then comes the security analysis.
Then the questions "are the benefits worth the risk"?

In many cases, the answer may be "yes". IN other it may be "no". There's
no "one size fits all".

Complexity could be reduced by RAs announcing routes and RDNSS where any
AAAA records in DNS are filtered and any other IPv6 traffic is
black-holed.

That is increased complexity itself.

Post by Fernando Gont
If I don't know how to handle a gun, I'd probably wouldn't have one in
the first place. But if I *was* handled one, then I'd probably leave it
as quite as possible, rather than start loading bullets and playing with
the trigger, as if I knew what I was doing....

How could you perform an ND-based attack if IPv6 is disabled at the
kernel level?

And no, I'm not arguing that you shouldn't monitor v6 just because
you've disabled it.

Post by Douglas Otis
Please overcome misconceptions regarding NATs and IPv6. Whether IPv6 or
IPv4 is used, a LAN is vulnerable without SeND.

A network is always vulnerable. What changes is what it is vulnerable
to. And I personally don't belive in this sort of "silver bullet"...
particularly when a solution is hard to deploy, and it's associated
complexity is well above 0.

Such complexity, by itself, is prone to introduce vulnerabilities in the
corresponding implementations.

Post by Douglas Otis
Middle Boxes such as
NATs remove many protections otherwise possible. The LAN is vulnerable
whether through ARP spoofing,

ARP traffic is *way* easier to monitor and police than ND traffic is.

Post by Douglas Otis
spanning tree or NAT table corruption,
etc. With RFC793 simultaneous-open handshakes, a Sneak Ack Attack can
reverse the logical direction of connection setups.

TCP simultaneous opens are not supported by all OSes. If that was the
case, we'd probably not need syn cookies or syn caches. Pleasee see the
corresponding discussion about "SYN flood attacks" in:
http://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf

Post by Douglas Otis
Often applications don't notice when an SSL certificate fails to match
against a domain. Even with SSL, Middle Boxes offer easy MitM
exploits. It is absurd to describe NATs as offering improved
protection.

Nobody argued that. But it's true that when deploying a NAT you get a
"only allow return traffic" stateful firewall as a side effect.

Post by Douglas Otis
Practices that depend on NAT "security" invite prone
systems that do more harm. IMHO, it is easier to firewall IPv6 than
deal with IPv4 related nonsense such as keep-alives,

huh? You'll have keep-alives in v6 if you do stateful firewalling...

Post by Douglas Otis
dynamic
translations, port mapping, etc.

There are many compromised CPE routers. An ISP's LSN are not likely to
be any worse.

A hacked CPE router only affects that customer. A hacked LSN affects all
customers that depend on that system. -- that's the difference.

Post by Fernando Gont
The bottom-line is that you should make sure that your "assumptions" are
correct. -- e.g., if you're argument for not applying specific v6
technologies is that "my network is v4-only", you better make sure
that's the case.

Assuring an assumption of "IPv4 Only" requires a sizable effort that
will prevent improved security from then being employed. :^(

Can you explicitly point out what you mean by "improved security"?

I cannot see why you argue that end-to-end security is only possible
with IPv6.

Do you argue that this is "deployable" in a tyipical organizational or
home network??

Post by Fernando Gont
When it comes to "filtering" as a mitigation for DoS, my take is that an
IPv6 /64 corresponds to what we currently do with a single IPv4 address.
Put another way, where in IPv4 you might be filtering a single IPv4
address or a small prefix, in IPv6 you'd be filtering at least a /64.
It would be worth adding, I agree.

There's no such a tihng as a "free lunch".

Some now hope in a new repute WG to base reputation on IP address
authorizations and message signatures that exclude who sent the message
and its intended recipient!

I wasn't aware about this ongoing work. Could you plkease provide some
pointers?

Thanks!

Best regards,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Jim Small

2011-09-27 01:37:31 UTC

In addition it would be appropriate to assume there WILL be an IPv6
firewall when IPv6 is enabled. Alternatively, it would be wrong to
assume any effective IPv6 firewall exists otherwise. Perhaps you could
replace "disable IPv6" with "disable Protocol 41" instead. :^)

"Disable proto 41" sounds good for referring to packets being filtered
at a firewall. However, other (not mutually exclusive) options are
avialable, such as disabling v6 suppport at the OS.

[JRS>] -and-

Exactly. Any compromised system within a LAN can easily set up IPv6
connectivity, specifically because a lax approach was taken where not
enabling IPv6 was seen as offering improved security. :^(

If you disable IPv6 in the sense of removing support for it, that attack
is not possible.

[JRS>] Specifically with Windows Vista/7/Server 2008/R2 and later IPv6 is a core part of the Operating System. Many features require IPv6 and will not work if you disable it including HyperV, TMG, Exchange, SBS Server, DirectAccess, HomeGroups, and Peer-to-Peer Networking.

I think we all agree there is a clear need for IPv6 and IPv4 is reaching the limits of its scalability. I like Fernando's approach of submitting drafts with suggestions where issues are discovered. I believe the focus should be on encouraging vendors to adopt existing solutions, maintain or achieve parity with IPv4 features, address limitations/vulnerabilities discovered, and actively participate in the IETF and other forums to drive and improve IPv6.

--Jim

Douglas Otis

2011-09-27 02:37:09 UTC

On 9/25/11 1:03 AM, Fernando Gont wrote:

Hi Fernando,

Post by Douglas Otis
The Brief overview on auto-configuration should mention RDNSS/DNSSL RA
options.

Yes. DHCP is NOT required by IPv6 to support DNS. This impacts
security that depends upon DHCP snooping and should be mentioned.

Some consideration must be given in how to detect hosts when DHCPv6 is
not used. A rouge RA could easily implement Prefix Information and
RDNSS options where monitoring DHCPv6 would then not detect which hosts
were involved. The DUID offered by DHCPv6 will not relate to specific
hosts or their assigned assigned addresses. Remote-ID Option 37
described in RFC4649 might be used to replace DHCPv4 Option 82 to aid
the port/IP address mapping, but then what when DHCPv6 is not used?

Can you point out where this "increased security" comes from?

NAT mapping rarely offers security. SSL CBC has proven easily
exploitable once a MitM situation is established. NAT use places
reliance on the LAN to avoid address spoofing and related MitM
scenarios, much like that found with XSS. End to End security does not
require use of IPsec, although IPsec would be one such anti-MitM
alternative.

Post by Douglas Otis
The statement 'Pushing people to "Enable IPv6" point-and-click style is
simply insane' is deceptive.

While I might s/insane/incorrect/ (or the like), I do believe that
enabling a technology that one doesn't understand is a really bad idea.

Even the assumption IPv6 is not enabled is a flawed concept.

Sloppy wording: I should have said "deploy IPv6" rather than "enable IPv6".

Thoughtful deployment is still a better choice. IPv6 is here now and
the simpler approach is native support on the LAN.

"Disable proto 41" sounds good for referring to packets being filtered
at a firewall. However, other (not mutually exclusive) options are
avialable, such as disabling v6 suppport at the OS.

Disabling IPv6 at the host will break services that do not assure
functionality in this downgraded mode. Not deploying IPv6 on the LAN
also invites less secure fallback transitional schemes. When a host is
compromised, is it still safe to assume IPv6 is disabled? Is there
spoofing protection with ISATAP?

Post by Fernando Gont
-- If whoever enabled v6 needed "5-step recipe to enable v6" or the
like, then they probably should have been trained before enabling v6.

Again, the message should be that IPv6 _already_ exits within their
networks.

Agreed. This is is noted in several slides. e.g., the first few ones,
and the "IPv6 security implications on IPv4 networks".

Post by Douglas Otis
Enabling IPv6 on the LAN permits better monitoring and
suppresses more problematic fallback strategies.

It also enables pontential vulnerabilities. See the latest (?)
remotely-explotaible vulnerability in OpenBSD dated 2008 or so.

When will these issues be resolved to meet your satisfaction? FreeBSD
vendors have already released patches for the issue where perhaps due to
the BSD license, fixes are driven by affected vendors. All the more
reason for the market to insist repairs are made or find alternatives.
Going back to IPv4 is not an alternative at this time.

Post by Fernando Gont
If you don't know "good enough" how your network works, attackers will
probably do better.

Exactly. Any compromised system within a LAN can easily set up IPv6
connectivity, specifically because a lax approach was taken where not
enabling IPv6 was seen as offering improved security. :^(

If you disable IPv6 in the sense of removing support for it, that attack
is not possible.

As in removing it from the Internet, from the router, from the switch?
Providing reasonable security for remote systems is easier using of
end-to-end security methods. IPv4 refers to translated IP address space
full of questionable middle boxes. While indeed IPv6 is not perfect,
IPv6 provides future growth.

Post by Douglas Otis
It is wrong to suggest _not_ enabling IPv6
in a network offers improved protections.

Well, I'd not say that it "provides improved protection", but rather
than "does not increase risk".

Disagree. This view increases risks by offering the false concept that
relative inaction is better.

Nobody said that. Please look at the slides. On the contrary, I'd argue
that *something* should be done about it.

Your strongest statements are to disable IPv6 (at the host), as if
practical, possible, or offering better security. Securely using IPv6
is the new cost of doing business, period.

Post by Douglas Otis
By suggesting a NEED to enable IPv6 within
the LAN raises attention to the fact that IPv6 is already present and
the related risks MUST be mitigated or at least monitored.

Should everyone stop using SSL because of the CBC issue? Many of these
issues will require improved monitoring over what we have today. Those
that start now will be ready when IPv6 really takes off, as it is about
to do.

Post by Fernando Gont
First of all comes an assessment of what the organization would gain
from enabling IPv6 (along with considering possible alternatives).
Then comes the security analysis.
Then the questions "are the benefits worth the risk"?
In many cases, the answer may be "yes". IN other it may be "no". There's
no "one size fits all".

More systems will remain vulnerable longer as malefactors take advantage
of "IPv6 broken" networks as they leak data over unseen transitional
protocols. :^(

Complexity could be reduced by RAs announcing routes and RDNSS where any
AAAA records in DNS are filtered and any other IPv6 traffic is
black-holed.

That is increased complexity itself.

Exactly. This was tongue in cheek. I even said it would not prevent
any exploits.

How could you perform an ND-based attack if IPv6 is disabled at the
kernel level?

There are many exploits that will always remain possible. Whether by
spoofing ARP broadcasts, spanning tree protocols, VLANs, etc. Progress
is made by achieving an environment able to offer end-to-end security.
While not everything needs to operate in this way, it is vitally
important more networks make progress in this direction where data is
secured by direct communication. More work needs to be done on DNSSEC,
SeND, DANE, etc. SeND can work within mixed environments and not be
supported by all hosts. Security can step over less secure hosts for
now and be limited to Cisco and Juniper routers and switches where
security is important.

Post by Fernando Gont
And no, I'm not arguing that you shouldn't monitor v6 just because
you've disabled it.

Additional monitoring will be fairly unlikely when they think no one is
using IPv6.

Post by Douglas Otis
Please overcome misconceptions regarding NATs and IPv6. Whether IPv6 or
IPv4 is used, a LAN is vulnerable without SeND.

A network is always vulnerable. What changes is what it is vulnerable
to. And I personally don't belive in this sort of "silver bullet"...
particularly when a solution is hard to deploy, and it's associated
complexity is well above 0.
Such complexity, by itself, is prone to introduce vulnerabilities in the
corresponding implementations.

That is what they said about SSL. :^) One might hope DANE and dynamic
DNSSEC becomes available, where support for SeND then becomes eas to
deploy.

Post by Douglas Otis
Middle Boxes such as
NATs remove many protections otherwise possible. The LAN is vulnerable
whether through ARP spoofing,

ARP traffic is *way* easier to monitor and police than ND traffic is.

There is no universal defense against ARP or ND spoofing. And it is
common for interfaces to utilize many IP addresses. Using static MAC
tables might help, but often that is not practical. While neither ARP
nor ND traffic can be completely enforced, that was the goal behind
SeND. Do we need to wait for the value of security and cost of the
hardware to become comparable? It is foolish to think either ND or ARP
are secure.

Post by Douglas Otis
spanning tree or NAT table corruption,
etc. With RFC793 simultaneous-open handshakes, a Sneak Ack Attack can
reverse the logical direction of connection setups.

TCP simultaneous opens are not supported by all OSes. If that was the
case, we'd probably not need syn cookies or syn caches. Pleasee see the
http://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf

Dropping packets that combine SYN and RST flags seems logical as well,
but even that is not a complete solution.

Nobody argued that. But it's true that when deploying a NAT you get a
"only allow return traffic" stateful firewall as a side effect.

When done with IPv6, the states are simpler. Far fewer keep-alives and
no dynamic reassignment of the destination address. When a subsequent
middle box is not present, there are fewer opportunities where traffic
can injected within the LAN. There are two types of LAN. Those that
have been compromised, and those that compromise has not yet been
discovered.

Post by Douglas Otis
Practices that depend on NAT "security" invite prone
systems that do more harm. IMHO, it is easier to firewall IPv6 than
deal with IPv4 related nonsense such as keep-alives,

huh? You'll have keep-alives in v6 if you do stateful firewalling...

Any duration in regard to IPv6 can have much longer periods without any
risk of running out of port resources.

Post by Douglas Otis
dynamic
translations, port mapping, etc.

There are many compromised CPE routers. An ISP's LSN are not likely to
be any worse.

A hacked CPE router only affects that customer. A hacked LSN affects all
customers that depend on that system. -- that's the difference.

Do we agree NATs offer poor security? To a user, they'll suffer the
same attack. For the attacker, one would hope the LSN has improved
monitoring over what is found in CPE, which is as good a none.

Assuring an assumption of "IPv4 Only" requires a sizable effort that
will prevent improved security from then being employed. :^(

Can you explicitly point out what you mean by "improved security"?

The ability to establish a paradigm of end-to-end security.

I cannot see why you argue that end-to-end security is only possible
with IPv6.

Do you argue that this is "deployable" in a tyipical organizational or
home network??

It is deployable when security holds enough value for the organization.

There's no such a thing as a "free lunch".

Or a practical solution that depends on massive IP address lists. IMHO,
this needs to move to crypto validation and interim tables ASAP, a la DANE.

Some now hope in a new repute WG to base reputation on IP address
authorizations and message signatures that exclude who sent the message
and its intended recipient!

I wasn't aware about this ongoing work. Could you please provide some
pointers?

http://tools.ietf.org/agenda/81/repute.html

Their charter refers to protocols that can not fairly support negative
reputation assessments. I am working on a paper to describe details of
the concerns.

-Doug

QUAKER DOOMER

2011-09-21 17:27:11 UTC

Jim Small

2011-09-21 18:31:53 UTC

Fernando,

This is great - thanks for sharing. If you do a 2nd version I have a few suggestions:
1) Talk about Ping-Pong problem on point-to-point interfaces/networks
2) Talk about NDP exhaustion attack/issues

Also I think this brings up two more issues:
1) IPv6 on a sizeable network will almost require an IPAM solution
2) IPv6 will essentially require DNS and for security DNSSec/Securely implemented DNS - you can't really memorize all your key IPv6 addresses like you can in IPv4. While this is obvious to anyone working with IPv6 I don't think it has hit home with the majority of network administrators who typically administer network devices by IP address.

I couldn't agree more on the education point. IPv6 is not rocket science but there are a surprising amount of those "little" details when you start implementing it.

--Jim

-----Original Message-----
From: ipv6hackers-***@lists.si6networks.com [mailto:ipv6hackers-***@lists.si6networks.com] On Behalf Of Fernando Gont
Sent: Wednesday, September 21, 2011 1:11 PM
To: IPv6 Hackers Mailing List
Subject: [ipv6hackers] IPv6 security presentation at Hack.lu 2011

Folks,

We have uploaded the slides of the IPv6 Security talk I gave at Hack.lu
2011. The slides are available at:
<http://www.si6networks.com/presentations/hacklu2011/fgont-hacklu2011-ipv6-security.pdf>

If there are any topics in the slides that that you think might benefit
from debate/discussion/brainstorming, please feel free to post to the list.

Thanks!

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

fred

2011-09-21 19:21:15 UTC

Hi Douglas,

This is really interesting. I realized that NAT was an easy target for DoS
attacks but I never read anything about this before...

I can see approximately how this may occur but if you have more doc about
this I am interested.

Thanks

--
Fred Bovy
***@fredbovy.com
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013

Joakim Aronius

2011-09-22 08:29:59 UTC

All nodes that keep state are vulnerable to DoS. Arbor Networks published a pretty intersting report which can be downloaded here:
http://www.arbornetworks.com/report

Regards,
/joakim

Post by fred
Hi Douglas,
This is really interesting. I realized that NAT was an easy target for DoS
attacks but I never read anything about this before...
I can see approximately how this may occur but if you have more doc about
this I am interested.
Thanks

--
Fred Bovy
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Jean-Michel Combes

2011-09-21 22:36:17 UTC

Hi Fernando,

At first thanks for the slides! Great job summarizing the state of the
art about IPv6 security!

Now, I have comments:
- Address resolution
"SEND is very difficult to deploy (it requires a PKI)"
AFAIK, you don't need a PKI. CGA is enough to secure NS/NA exchanges.
Now, the main issue, IMHO, is hard-coded crypto algorithms: SHA-1,
that should be replaced by the future SHA-3, and RSA, which is not
very well adapted to constrained devices like sensors.
- Auto-configuration
"SEND is very difficult to deploy (it requires a PKI)"
s/PKI/RPKI (cf. draft-ietf-csi-send-cert)
And again, AFAIK, RIRs are currently working to deploy RPKI (e.g.,
http://www.rpki.net for ARIN) and openssl already allows to generate
the needed certificates. Now I agree there is still work to deploy
this technology in product networks.
- IPsec Support
"The IETF has acknowledged this fact, and is currently changing IPsec
support in IPv6 to “optional”"
Sorry, but IPsec support is still a "SHOULD" (v.s. "MAY" meaning
optional) and so IPsec is not optional unless specific constraints
(like sensors).
Now, as raised many times, the main issue with IPsec is Key Management
(e.g., pre-shared key, certs, EAP).

Best regards.

JMC.

Post by Fernando Gont
Folks,
We have uploaded the slides of the IPv6 Security talk I gave at Hack.lu
<http://www.si6networks.com/presentations/hacklu2011/fgont-hacklu2011-ipv6-security.pdf>
If there are any topics in the slides that that you think might benefit
from debate/discussion/brainstorming, please feel free to post to the list.
Thanks!
--
Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Arturo Servin

2011-09-22 00:37:11 UTC

Jean,

Post by Jean-Michel Combes
Hi Fernando,
At first thanks for the slides! Great job summarizing the state of the
art about IPv6 security!
- Address resolution
"SEND is very difficult to deploy (it requires a PKI)"
AFAIK, you don't need a PKI. CGA is enough to secure NS/NA exchanges.
Now, the main issue, IMHO, is hard-coded crypto algorithms: SHA-1,
that should be replaced by the future SHA-3, and RSA, which is not
very well adapted to constrained devices like sensors.
- Auto-configuration
"SEND is very difficult to deploy (it requires a PKI)"
s/PKI/RPKI (cf. draft-ietf-csi-send-cert)
And again, AFAIK, RIRs are currently working to deploy RPKI (e.g.,
http://www.rpki.net for ARIN) and openssl already allows to generate
the needed certificates. Now I agree there is still work to deploy
this technology in product networks.

I think your are mixing concepts. RPKI does have to do anything with SEND.

Regarding SEND AFAIK, you need a certificate in each device requesting network information to validate the source. For that requirement only, SEND is not easy to deploy.

Post by Jean-Michel Combes
- IPsec Support
"The IETF has acknowledged this fact, and is currently changing IPsec
support in IPv6 to “optional”"
Sorry, but IPsec support is still a "SHOULD" (v.s. "MAY" meaning
optional)

MAY is optional, SHOULD recommended and MUST is mandatory. (RFC2119)

RFC4294 has IPSec (rfc4301) as MUST. But that's going to change soon:

http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-11

"Previously, IPv6 mandated implementation of IPsec and recommended the
key management approach of IKE. This document updates that
recommendation by making support of the IP Security Architecture [RFC
4301] a SHOULD for all IPv6 nodes. "

So, it is as Fernando say. It is MUST but it's going to be SHOULD.

Post by Jean-Michel Combes
and so IPsec is not optional unless specific constraints
(like sensors).
Now, as raised many times, the main issue with IPsec is Key Management
(e.g., pre-shared key, certs, EAP).
Best regards.
JMC.

Regards,
/as

Gert Doering

2011-09-22 18:01:19 UTC

Hi,

Post by Arturo Servin
Jean,
Regarding SEND AFAIK, you need a certificate in each device requesting network information to validate the source. For that requirement only, SEND is not easy to deploy.

You need the PKI infrastructure to validate RAs.

For securing ND, you need CGAs, and those are (sort of) self-contained
CERTs (strongly simplified). So no PKI structure is needed there - but
of course you can't do SEND with arbitrary IPv6 addresses on the hosts.

Gert Doering
-- NetMaster

--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

Fernando Gont

2011-09-24 21:23:07 UTC

Post by Gert Doering

Jean, Regarding SEND AFAIK, you need a certificate in each device
requesting network information to validate the source. For that
requirement only, SEND is not easy to deploy.

You need the PKI infrastructure to validate RAs.

If you don't validate RA's, then an attacker would simply spoof RA's,
and would have all packets forwarded to him, thus defeating any
protection that could have been provided with the CGAs.

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Owen DeLong

2011-09-25 09:39:52 UTC

Post by Gert Doering

Jean, Regarding SEND AFAIK, you need a certificate in each device
requesting network information to validate the source. For that
requirement only, SEND is not easy to deploy.

You need the PKI infrastructure to validate RAs.

If you don't validate RA's, then an attacker would simply spoof RA's,
and would have all packets forwarded to him, thus defeating any
protection that could have been provided with the CGAs.

Unless you use RA Guard instead.

Owen

Post by Fernando Gont
Thanks,
--
Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Marc Heuse

2011-09-25 09:55:07 UTC

Post by Gert Doering

Jean, Regarding SEND AFAIK, you need a certificate in each device
requesting network information to validate the source. For that
requirement only, SEND is not easy to deploy.

You need the PKI infrastructure to validate RAs.

If you don't validate RA's, then an attacker would simply spoof RA's,
and would have all packets forwarded to him, thus defeating any
protection that could have been provided with the CGAs.

Unless you use RA Guard instead.

and in the current state of RA implementations and IPv6 implementation
into the OSes, RA guard can easily be bypassed.

Greets,
Marc

--
Marc Heuse
Mobil: +49 177 9611560
Fax: +49 30 37309726
www.mh-sec.de

Marc Heuse - IT-Security Consulting
Winsstr. 68
10405 Berlin

Ust.-Ident.-Nr.: DE244222388
PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A

s***@nethelp.no

2011-09-25 12:57:51 UTC

Post by Marc Heuse

Post by Fernando Gont
If you don't validate RA's, then an attacker would simply spoof RA's,
and would have all packets forwarded to him, thus defeating any
protection that could have been provided with the CGAs.

Unless you use RA Guard instead.

and in the current state of RA implementations and IPv6 implementation
into the OSes, RA guard can easily be bypassed.

Can you be more detailed about how? Are you, for instance, thinking
of using multiple IPv6 extension headers to bypass checking?

Steinar Haug, Nethelp consulting, ***@nethelp.no

Marc Heuse

2011-09-25 13:21:00 UTC

Post by s***@nethelp.no

Post by Marc Heuse

Unless you use RA Guard instead.

and in the current state of RA implementations and IPv6 implementation
into the OSes, RA guard can easily be bypassed.

Can you be more detailed about how? Are you, for instance, thinking
of using multiple IPv6 extension headers to bypass checking?

I documented that some months ago on a different mailing list, this one
did not exist back then:

http://www.gossamer-threads.com/lists/nsp/ipv6/29766

(and as I can see from the message thread - you even replied to it ;-) )

Greets,
Marc

--
Marc Heuse
Mobil: +49 177 9611560
Fax: +49 30 37309726
www.mh-sec.de

Marc Heuse - IT-Security Consulting
Winsstr. 68
10405 Berlin

Ust.-Ident.-Nr.: DE244222388
PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A

Fernando Gont

2011-09-25 15:04:31 UTC

Unless you use RA Guard instead.

Please take a look at our blog:
<http://blog.si6networks.com/2011/09/router-advertisement-guard-ra-guard.html>

You may also take a look at http://www.thc.org for a publicly available
tool that implements at least some of the variants described in our blog.

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Jean-Michel Combes

2011-09-22 18:31:50 UTC

Hi Arturo,

Jean,

I think your are mixing concepts. RPKI does have to do anything with SEND.

Please, read the draft and you should see the relationship with SIDR
WG works and so RPKI.

Regarding SEND AFAIK, you need a certificate in each device requesting network information to validate the source. For that requirement only, SEND is not easy to deploy.

MAY is optional, SHOULD recommended and MUST is mandatory. (RFC2119)

Agree :)

http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-11
"Previously, IPv6 mandated implementation of IPsec and recommended the
key management approach of IKE. This document updates that
recommendation by making support of the IP Security Architecture [RFC
4301] a SHOULD for all IPv6 nodes. "
So, it is as Fernando say. It is MUST but it's going to be SHOULD.

Please, read again what I said in my previous email :)

Best regards.

JMC.

Regards,
/as
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Arturo Servin

2011-09-22 18:45:27 UTC

Jean,

Post by Jean-Michel Combes
Hi Arturo,

I think your are mixing concepts. RPKI does have to do anything with SEND.

Please, read the draft

Which one, there are like 10.

Post by Jean-Michel Combes
and you should see the relationship with SIDR
WG works and so RPKI.

The only common thing between RPKI and SEND is that both use PKI. No more.

I do not see your point to bring up RPKI and RIR work along with SEND. I just cannot find the connection (besides that both are PKIs).

.as

Jean-Michel Combes

2011-09-22 19:22:50 UTC

Jean,

Post by Jean-Michel Combes
Hi Arturo,

Jean,

[snip]

Post by Jean-Michel Combes
- Auto-configuration
"SEND is very difficult to deploy (it requires a PKI)"
s/PKI/RPKI (cf. draft-ietf-csi-send-cert)
And again, AFAIK, RIRs are currently working to deploy RPKI (e.g.,
http://www.rpki.net for ARIN) and openssl already allows to generate
the needed certificates. Now I agree there is still work to deploy
this technology in product networks.

I think your are mixing concepts. RPKI does have to do anything with SEND.

Please, read the draft

Which one, there are like 10.

Last version, so *-10 (which has RFC Ed Queue status).

Post by Jean-Michel Combes
and you should see the relationship with SIDR
WG works and so RPKI.

The only common thing between RPKI and SEND is that both use PKI. No more.

OK. At first, I am not a PKI expert. Now, from what I understand (PKI
experts, please, don't hesitate to correct me :)):

RPKI is based on SPKI, meaning you don't care who is the owner of the
certificate (i.e., DN) but you only need to know an entity is allowed
to provide a service. This is not the case in a classical PKI (i.e.,
applications check DN in the cert).

I do not see your point to bring up RPKI and RIR work along with SEND. I just cannot find the connection (besides that both are PKIs).

RPKI is used to certify resources (i.e., AS and Prefixes). The Trust
Anchors (i.e., CA) are normally the RIRs. So, in a SEND deployment,
the hosts should only store RIRs' certificates to get

.as
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Jean-Michel Combes

2011-09-22 19:24:24 UTC

Jean,

Post by Jean-Michel Combes
Hi Arturo,

Jean,

[snip]

I think your are mixing concepts. RPKI does have to do anything with SEND.

Please, read the draft

Which one, there are like 10.

Last version, so *-10 (which has RFC Ed Queue status).

Post by Jean-Michel Combes
and you should see the relationship with SIDR
WG works and so RPKI.

The only common thing between RPKI and SEND is that both use PKI. No more.

OK. At first, I am not a PKI expert. Now, from what I understand (PKI
RPKI is based on SPKI, meaning you don't care who is the owner of the
certificate (i.e., DN) but you only need to know an entity is allowed
to provide a service. This is not the case in a classical PKI (i.e.,
applications check DN in the cert).

I do not see your point to bring up RPKI and RIR work along with SEND. I just cannot find the connection (besides that both are PKIs).

RPKI is used to certify resources (i.e., AS and Prefixes). The Trust
Anchors (i.e., CA) are normally the RIRs. So, in a SEND deployment,
the hosts should only store RIRs' certificates to get

ooops .... wrong manipulation :s

... to get the right certification path. Is it clearer?

Best regards.

JMC.

.as
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Arturo Servin

2011-09-22 19:30:41 UTC

Not really.

It is getting worse.

In RPKI RIRs are issuing certificates to entities that have received resources (IPv4, IPv6 and ASNs) from them. Those entities will use those certificates to create other objects (called ROAs) that will be used by routers to perform origin validation in BGP.

It has to do nothing with SEND.

And there are several documents describing RPKI, not just one. See (basically the ones in the Editors Queue):

http://tools.ietf.org/wg/sidr/

Regards.
as

Post by Jean-Michel Combes
Hi Arturo,

[snip]

I think your are mixing concepts. RPKI does have to do anything with SEND.

Please, read the draft

Which one, there are like 10.

Last version, so *-10 (which has RFC Ed Queue status).

Post by Jean-Michel Combes
and you should see the relationship with SIDR
WG works and so RPKI.

The only common thing between RPKI and SEND is that both use PKI. No more.

Post by Arturo Servin
I do not see your point to bring up RPKI and RIR work along with SEND. I just cannot find the connection (besides that both are PKIs).

RPKI is used to certify resources (i.e., AS and Prefixes). The Trust
Anchors (i.e., CA) are normally the RIRs. So, in a SEND deployment,
the hosts should only store RIRs' certificates to get

ooops .... wrong manipulation :s
... to get the right certification path. Is it clearer?
Best regards.
JMC.

Post by Arturo Servin
.as
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Geoff Huston

2011-09-22 19:45:10 UTC

Post by Arturo Servin
Not really.
It is getting worse.
In RPKI RIRs are issuing certificates to entities that have received resources (IPv4, IPv6 and ASNs) from them. Those entities will use those certificates to create other objects (called ROAs) that will be used by routers to perform origin validation in BGP.
It has to do nothing with SEND.
http://tools.ietf.org/wg/sidr/
Regards.
as

Actually, as far as I am aware the answer is yes, RPKI can be used to support EE certs issued to routers, or at least that was the intention back in 2009 when we were working on the RPKI and SEND documents in the IETF.

In the RPKI specs we added the following in the certificate profile:

4.8.5. Extended Key Usage

The Extended Key Usage (EKU) extension MUST NOT appear in any CA
certificate in the RPKI. This extension also MUST NOT appear in EE
certificates used to verify RPKI objects (e.g., ROAs or manifests.
The extension MUST NOT be marked critical.

The EKU extension MAY appear in EE certificates issued to routers or
other devices. Permitted values for the EKU OIDs will be specified
in Standards Track RFCs issued by other IETF working groups that
adopt the RPKI profile and that identify application-specific
requirements that motivate the use of such EKUs.

So with the EKU extension RPKI EE certs can be issued to SEND routers.

The following text was proposed to the SEND document to match this:

End entity certificates issued in support of SeND MUST comply with the RPKI resource profile [res-certificate-profile]. CA certificates used to verify these router (EE) certificates also MUST comply with this profile. This implies that these CA certificates MUST contain at an RFC 3779 address extension representing the address space allocations held by the service provider represented by the CA.

Relying parties (e.g., user devices that implement SeND and process these router certificates) MUST be configured with one or more trust anchors, to enable validation of the router certificates. These trust anchors MAY be the default trust anchors defined for the RPKI, or they MAY be self-signed (CA) certificates associated with the service providers operating the routers in question. In either case, it is RECOMMENDED that the RPKI trust anchor representation defined in [res-certificate-profile] be employed.

Because of the flexibility afforded service through (local) trust anchor configuration, certificates used for SeND support can be issued prior to issuance of RPKI certificates under the global address allocation hierarchy. Note, however, that a CA certificate issued independently of the global RPKI will have to be reissued in order to integrate a local PKI with the global RPKI.

---
End entity certificates issued to routers in support of SeND applications MUST contain an Extended Key Usage (EKU) extension. The inclusion of this extension, using one or more of the values defined here, is consistent with the RPKI resource certificate profile [res-certificate-profile], since explicit provision is made for using this extension in such contexts.

probably a good idea to check with the SEND documents to see where all this ended up

regards,

Geoff

Jean-Michel Combes

2011-09-22 19:57:50 UTC

Post by Geoff Huston

Not really.
It is getting worse.
In RPKI RIRs are issuing certificates to entities that have received resources (IPv4, IPv6 and ASNs) from them. Those entities will use those certificates to create other objects (called ROAs) that will be used by routers to perform origin validation in BGP.
It has to do nothing with SEND.
http://tools.ietf.org/wg/sidr/
Regards.
as

Yes, that was the main reason for draft-ietf-csi-send-cert submission
in CSI WG: to be compliant with RPKI specifications in SIDR WG.

Best regards.

JMC.

[snip]

Post by Geoff Huston
Geoff
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Geoff Huston

2011-09-22 20:02:08 UTC

Post by Jean-Michel Combes
Yes, that was the main reason for draft-ietf-csi-send-cert submission
in CSI WG: to be compliant with RPKI specifications in SIDR WG.

aha!! _that_ was the document that I was looking for! Thanks for the pointer!

Geoff

Arturo Servin

2011-09-22 19:57:59 UTC

Geoff,

Thanks, I did not know that we could do that with EE certificates. You have trigger some curiosity to dig more on SEND.

regards,
-as

Post by Geoff Huston

Actually, as far as I am aware the answer is yes, RPKI can be used to support EE certs issued to routers, or at least that was the intention back in 2009 when we were working on the RPKI and SEND documents in the IETF.
4.8.5. Extended Key Usage
The Extended Key Usage (EKU) extension MUST NOT appear in any CA
certificate in the RPKI. This extension also MUST NOT appear in EE
certificates used to verify RPKI objects (e.g., ROAs or manifests.
The extension MUST NOT be marked critical.
The EKU extension MAY appear in EE certificates issued to routers or
other devices. Permitted values for the EKU OIDs will be specified
in Standards Track RFCs issued by other IETF working groups that
adopt the RPKI profile and that identify application-specific
requirements that motivate the use of such EKUs.
So with the EKU extension RPKI EE certs can be issued to SEND routers.
End entity certificates issued in support of SeND MUST comply with the RPKI resource profile [res-certificate-profile]. CA certificates used to verify these router (EE) certificates also MUST comply with this profile. This implies that these CA certificates MUST contain at an RFC 3779 address extension representing the address space allocations held by the service provider represented by the CA.
Relying parties (e.g., user devices that implement SeND and process these router certificates) MUST be configured with one or more trust anchors, to enable validation of the router certificates. These trust anchors MAY be the default trust anchors defined for the RPKI, or they MAY be self-signed (CA) certificates associated with the service providers operating the routers in question. In either case, it is RECOMMENDED that the RPKI trust anchor representation defined in [res-certificate-profile] be employed.
Because of the flexibility afforded service through (local) trust anchor configuration, certificates used for SeND support can be issued prior to issuance of RPKI certificates under the global address allocation hierarchy. Note, however, that a CA certificate issued independently of the global RPKI will have to be reissued in order to integrate a local PKI with the global RPKI.
---
End entity certificates issued to routers in support of SeND applications MUST contain an Extended Key Usage (EKU) extension. The inclusion of this extension, using one or more of the values defined here, is consistent with the RPKI resource certificate profile [res-certificate-profile], since explicit provision is made for using this extension in such contexts.
probably a good idea to check with the SEND documents to see where all this ended up
regards,
Geoff

Fernando Gont

2011-09-25 07:25:44 UTC

Hi, Geoff,

Post by Geoff Huston
Actually, as far as I am aware the answer is yes, RPKI can be used to
support EE certs issued to routers, or at least that was the
intention back in 2009 when we were working on the RPKI and SEND
documents in the IETF.

Even with this in place, I don't see how this would make SEND deployment
easier for an edge network.

Are e.g. home/organisational networks expected to receive a certificate
from their ISPs such that they can use SEND as a mitigation for ND-based
attacks?

Leveraging RPKI might make sense for some carrier/ISP networks, but I
can't see how that would ease SEND deployment for the general case.

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Jean-Michel Combes

2011-09-26 11:38:55 UTC

Hi Fernando,

Post by Fernando Gont
Hi, Geoff,

<ISP hat on>
Yes, could be the case.
Now, IMHO, still missing tools do to this: we have already PD with
DHCPv6 but we would need something to provide, dynamically too, the
associated certs (e.g., draft-popoviciu-dhc-certificate-opt).
<ISP hat off>

Best regards.

JMC.

Post by Fernando Gont
Leveraging RPKI might make sense for some carrier/ISP networks, but I
can't see how that would ease SEND deployment for the general case.
Thanks,
--
Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Jean-Michel Combes

2011-09-22 19:54:39 UTC

Not really.
It is getting worse.

Argh .... :s

In RPKI RIRs are issuing certificates to entities that have received resources (IPv4, IPv6 and ASNs) from them.

Yes! Just keep this in mind ...

Those entities will use those certificates to create other objects (called ROAs) that will be used by routers to perform origin validation in BGP.

For SEND, forget this :)

It has to do nothing with SEND.

Simple example:

RIRs, when allocating a prefix to a LIR (I skip NIR :)), will provide
also, as CA, the cert associated to the allocated prefix. OK?
LIR will allocate a sub-prefix to his customers with the certs (signed
by the LIR, i.e, the LIR becomes a Sub CA) associated to the allocated
sub-prefix, OK ?
Finally, the customer will configure this sub-prefix on his router and
use the cert provided by his LIR with SEND. OK?
So, the host will be able to find a certification path to a CA, the RIR.

Clearer?

Best regards.

JMC.

http://tools.ietf.org/wg/sidr/
Regards.
as

Jean,

Post by Jean-Michel Combes
Hi Arturo,

Jean,

[snip]

I think your are mixing concepts. RPKI does have to do anything with SEND.

Please, read the draft

Which one, there are like 10.

Last version, so *-10 (which has RFC Ed Queue status).

Post by Jean-Michel Combes
and you should see the relationship with SIDR
WG works and so RPKI.

The only common thing between RPKI and SEND is that both use PKI. No more.

I do not see your point to bring up RPKI and RIR work along with SEND. I just cannot find the connection (besides that both are PKIs).

RPKI is used to certify resources (i.e., AS and Prefixes). The Trust
Anchors (i.e., CA) are normally the RIRs. So, in a SEND deployment,
the hosts should only store RIRs' certificates to get

ooops .... wrong manipulation :s
... to get the right certification path. Is it clearer?
Best regards.
JMC.

.as
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Arturo Servin

2011-09-22 19:58:43 UTC

Jean,

Now with Geoff input I get your point.

-as

Post by Arturo Servin
Not really.
It is getting worse.

Argh .... :s

Post by Arturo Servin
In RPKI RIRs are issuing certificates to entities that have received resources (IPv4, IPv6 and ASNs) from them.

Yes! Just keep this in mind ...

Post by Arturo Servin
Those entities will use those certificates to create other objects (called ROAs) that will be used by routers to perform origin validation in BGP.

For SEND, forget this :)

Post by Arturo Servin
It has to do nothing with SEND.

RIRs, when allocating a prefix to a LIR (I skip NIR :)), will provide
also, as CA, the cert associated to the allocated prefix. OK?
LIR will allocate a sub-prefix to his customers with the certs (signed
by the LIR, i.e, the LIR becomes a Sub CA) associated to the allocated
sub-prefix, OK ?
Finally, the customer will configure this sub-prefix on his router and
use the cert provided by his LIR with SEND. OK?
So, the host will be able to find a certification path to a CA, the RIR.
Clearer?
Best regards.
JMC.

Post by Arturo Servin
http://tools.ietf.org/wg/sidr/
Regards.
as

Post by Jean-Michel Combes
Hi Arturo,

[snip]

I think your are mixing concepts. RPKI does have to do anything with SEND.

Please, read the draft

Which one, there are like 10.

Last version, so *-10 (which has RFC Ed Queue status).

Post by Jean-Michel Combes
and you should see the relationship with SIDR
WG works and so RPKI.

The only common thing between RPKI and SEND is that both use PKI. No more.

Post by Arturo Servin
I do not see your point to bring up RPKI and RIR work along with SEND. I just cannot find the connection (besides that both are PKIs).

RPKI is used to certify resources (i.e., AS and Prefixes). The Trust
Anchors (i.e., CA) are normally the RIRs. So, in a SEND deployment,
the hosts should only store RIRs' certificates to get

ooops .... wrong manipulation :s
... to get the right certification path. Is it clearer?
Best regards.
JMC.

Post by Arturo Servin
.as
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Jim Small

2011-09-22 00:21:06 UTC

The problem with SeND is limited O/S implementations. I know there is Linux support, but Windows doesn't support it and I don't believe OS X does either. There are many ideas for IPv6 security, mobility (MIPv6), and multi-homing (SHIM6) - but without mainstream native O/S support they seem to be limited to a lab. My impression is that Microsoft and Apple have essentially no interest in these areas.

--Jim

-----Original Message-----
From: ipv6hackers-***@lists.si6networks.com [mailto:ipv6hackers-***@lists.si6networks.com] On Behalf Of Jean-Michel Combes
Sent: Wednesday, September 21, 2011 6:36 PM
To: IPv6 Hackers Mailing List
Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011

Hi Fernando,

At first thanks for the slides! Great job summarizing the state of the
art about IPv6 security!

Now, I have comments:
- Address resolution
"SEND is very difficult to deploy (it requires a PKI)"
AFAIK, you don't need a PKI. CGA is enough to secure NS/NA exchanges.
Now, the main issue, IMHO, is hard-coded crypto algorithms: SHA-1,
that should be replaced by the future SHA-3, and RSA, which is not
very well adapted to constrained devices like sensors.
- Auto-configuration
"SEND is very difficult to deploy (it requires a PKI)"
s/PKI/RPKI (cf. draft-ietf-csi-send-cert)
And again, AFAIK, RIRs are currently working to deploy RPKI (e.g.,
http://www.rpki.net for ARIN) and openssl already allows to generate
the needed certificates. Now I agree there is still work to deploy
this technology in product networks.
- IPsec Support
"The IETF has acknowledged this fact, and is currently changing IPsec
support in IPv6 to "optional""
Sorry, but IPsec support is still a "SHOULD" (v.s. "MAY" meaning
optional) and so IPsec is not optional unless specific constraints
(like sensors).
Now, as raised many times, the main issue with IPsec is Key Management
(e.g., pre-shared key, certs, EAP).

Best regards.

JMC.

Eric Vyncke (evyncke)

2011-09-22 07:35:11 UTC

Indeed, right to the spot: SEND per se works (and CGA does not require PKI) but it not implemented in Windows & Apple (and AFAIK they have little incentive to do it: IPv6 parity with IPv4 where ARP was wide open to attack). I am afraid that OS vendors simply rely on network/switch vendors to come with a security mitigation technique (à la SAVI)

-éric

Post by Jim Small
-----Original Message-----
Sent: jeudi 22 septembre 2011 02:21
To: IPv6 Hackers Mailing List
Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
The problem with SeND is limited O/S implementations. I know there is Linux
support, but Windows doesn't support it and I don't believe OS X does
either. There are many ideas for IPv6 security, mobility (MIPv6), and
multi-homing (SHIM6) - but without mainstream native O/S support they seem
to be limited to a lab. My impression is that Microsoft and Apple have
essentially no interest in these areas.
--Jim
-----Original Message-----
Sent: Wednesday, September 21, 2011 6:36 PM
To: IPv6 Hackers Mailing List
Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
Hi Fernando,
At first thanks for the slides! Great job summarizing the state of the
art about IPv6 security!
- Address resolution
"SEND is very difficult to deploy (it requires a PKI)"
AFAIK, you don't need a PKI. CGA is enough to secure NS/NA exchanges.
Now, the main issue, IMHO, is hard-coded crypto algorithms: SHA-1,
that should be replaced by the future SHA-3, and RSA, which is not
very well adapted to constrained devices like sensors.
- Auto-configuration
"SEND is very difficult to deploy (it requires a PKI)"
s/PKI/RPKI (cf. draft-ietf-csi-send-cert)
And again, AFAIK, RIRs are currently working to deploy RPKI (e.g.,
http://www.rpki.net for ARIN) and openssl already allows to generate
the needed certificates. Now I agree there is still work to deploy
this technology in product networks.
- IPsec Support
"The IETF has acknowledged this fact, and is currently changing IPsec
support in IPv6 to "optional""
Sorry, but IPsec support is still a "SHOULD" (v.s. "MAY" meaning
optional) and so IPsec is not optional unless specific constraints
(like sensors).
Now, as raised many times, the main issue with IPsec is Key Management
(e.g., pre-shared key, certs, EAP).
Best regards.
JMC.

Post by Fernando Gont
Folks,
We have uploaded the slides of the IPv6 Security talk I gave at Hack.lu
<http://www.si6networks.com/presentations/hacklu2011/fgont-hacklu2011-

ipv6-security.pdf>

Post by Fernando Gont
If there are any topics in the slides that that you think might benefit
from debate/discussion/brainstorming, please feel free to post to the

list.

Post by Fernando Gont
Thanks!
--
Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Fernando Gont

2011-09-22 08:23:12 UTC

Eric,

Post by Eric Vyncke (evyncke)
Indeed, right to the spot: SEND per se works (and CGA does not
require PKI)

CGAs do not require a PKI. But if you don't use certificates, you don't
solve the problem of rogue routers, and hence you don't really get much
by using CGAs.

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Jim Small

2011-09-22 15:56:17 UTC

Karl,

To address your questions:
1) SeND (Secure Neighbor Discovery Protocol) Info including sources:
http://en.wikipedia.org/wiki/Secure_Neighbor_Discovery_Protocol
And a good overview (saw lots of comments on the list):
http://ipv6.com/articles/research/Secure-Neighbor-Discovery.htm

Ideally I could point you to a Live CD but I couldn't find one. I'll ask around and post back if I can find one. I know several people well who have setup SeND with Linux/IOS so I know it's possible.

2) Official proclamation from Microsoft the SeND is not implemented in Windows:
http://technet.microsoft.com/en-us/library/bb726956.aspx
Updated this August, from the Authorization for Automatically Assigned Addresses and Configurations section, "Microsoft does not support SEND in any version of Windows."

3) Definitive information on SeND support from Apple for OS X - unfortunately I couldn't find it. I'll post back if I can.

4) Bonus - How to setup SeND in IOS:
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_security.html#wp1112987

-

Jim Small

2011-09-23 00:52:21 UTC

Karl,

Definitive information on SeND support from Apple for OS X:
I pinged one of the Apple Core OS Developers and he said that the XNU kernel (OS X and iOS) does not implement SeND. So for now the answer is no. I don't have a link but if you want to double check you could post in the Apple Development Forums.

I haven't found/heard anything for a Linux Live CD with SeND and I'm not too optimistic that I will. You can compile it in with Linux or FreeBSD but it's up to you to make it work.

--Jim

Jean-Michel Combes

2011-09-22 18:48:33 UTC

Hi Jim,

Post by Jim Small
The problem with SeND is limited O/S implementations.

Yes, I agree. And, crypto algorithm constraints (i.e., SHA-1, RSA)
don't help too ... patch needed if CGA specifications are updated
resulting extra cost, plus interoperability issues between RFC3972
implementations and RFC3972bis implementations.

Post by Jim Small
I know there is Linux support,

AFAIK, SEND/CGA is better implemented on FreeBSD (i.e., the kernel has
been modified, IMHO, what is needed to be fully compliant with
SEND/CGA)

Post by Jim Small
but Windows doesn't support it and I don't believe OS X does either. There are many ideas for IPv6 security, mobility (MIPv6), and multi-homing (SHIM6) - but without mainstream native O/S support they seem to be limited to a lab.

+1 :s

Best regards.

JMC.

Post by Jim Small
My impression is that Microsoft and Apple have essentially no interest in these areas.
--Jim
-----Original Message-----
Sent: Wednesday, September 21, 2011 6:36 PM
To: IPv6 Hackers Mailing List
Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
Hi Fernando,
At first thanks for the slides! Great job summarizing the state of the
art about IPv6 security!
- Address resolution
"SEND is very difficult to deploy (it requires a PKI)"
AFAIK, you don't need a PKI. CGA is enough to secure NS/NA exchanges.
Now, the main issue, IMHO, is hard-coded crypto algorithms: SHA-1,
that should be replaced by the future SHA-3, and RSA, which is not
very well adapted to constrained devices like sensors.
- Auto-configuration
"SEND is very difficult to deploy (it requires a PKI)"
s/PKI/RPKI (cf. draft-ietf-csi-send-cert)
And again, AFAIK, RIRs are currently working to deploy RPKI (e.g.,
http://www.rpki.net for ARIN) and openssl already allows to generate
the needed certificates. Now I agree there is still work to deploy
this technology in product networks.
- IPsec Support
"The IETF has acknowledged this fact, and is currently changing IPsec
support in IPv6 to "optional""
Sorry, but IPsec support is still a "SHOULD" (v.s. "MAY" meaning
optional) and so IPsec is not optional unless specific constraints
(like sensors).
Now, as raised many times, the main issue with IPsec is Key Management
(e.g., pre-shared key, certs, EAP).
Best regards.
JMC.

fred

2011-09-22 16:15:09 UTC

Hi,

A bit more about SEND.
I was the CISCO IPv6 engineer who did the dev-test for SEND. I wrote the
test plan and all the TCL scripts to test it all and I also developed the
template to decode the protocol with the Cisco Internal tool...

I would have love to see Microsoft keeps its word and implements it in Vista
as I heard they will but once we (CISCO) developed it, then Microsoft did
not :-(

I wrote this post about SEND:
http://www.fastlaneus.com/blog/2011/08/30/secure-the-ipv6-network-access-wit
h-secure-neighbor-discovery-send-rfc3971-and-cga-rfc3972/

I believe that there would be no protocol safer than IPv6 if SEND was
implemented by Microsoft and Apple... It's a shame they did not!

Having PKI is not a big deal. We get a certificates in France in 10 minutes
from the French Tax when we do our tax return online ! And you only need to
do it sometimes. You don't need a new certificate everyday !

You also need strong time synchronization to make it work but this is not a
big issue neither.

The only big problem is that neither Microsoft neither Apple implemented it.

Fred

Post by Jim Small
Karl,
http://en.wikipedia.org/wiki/Secure_Neighbor_Discovery_Protocol
http://ipv6.com/articles/research/Secure-Neighbor-Discovery.htm
Ideally I could point you to a Live CD but I couldn't find one. I'll ask
around and post back if I can find one. I know several people well who have
setup SeND with Linux/IOS so I know it's possible.
2) Official proclamation from Microsoft the SeND is not implemented in
http://technet.microsoft.com/en-us/library/bb726956.aspx
Updated this August, from the Authorization for Automatically Assigned
Addresses and Configurations section, "Microsoft does not support SEND in any
version of Windows."
3) Definitive information on SeND support from Apple for OS X - unfortunately
I couldn't find it. I'll post back if I can.
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_sec
urity.html#wp1112987
--Jim
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

--
Fred Bovy
***@fredbovy.com
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013

Sara

2011-09-23 07:22:16 UTC

Hi All,
we already implemented SEND for windows however we're working on performance. I'm really interested to know more about CISCO implementation and other details if available because we would like to know what CISCO did about router certification and so on.

Regards,
Sara

________________________________
From: fred <***@fredbovy.com>
To: IPv6 Hackers Mailing List <***@lists.si6networks.com>; Karl Auer <***@biplane.com.au>
Sent: Thursday, September 22, 2011 6:15 PM
Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011

Hi,

A bit more about SEND.
I was the CISCO IPv6 engineer who did the dev-test for SEND. I wrote the
test plan and all the TCL scripts to test it all and I also developed the
template to decode the protocol with the Cisco Internal tool...

I would have love to see Microsoft keeps its word and implements it in Vista
as I heard they will but once we (CISCO) developed it, then Microsoft did
not :-(

I wrote this post about SEND:
http://www.fastlaneus.com/blog/2011/08/30/secure-the-ipv6-network-access-wit
h-secure-neighbor-discovery-send-rfc3971-and-cga-rfc3972/

I believe that there would be no protocol safer than IPv6 if SEND was
implemented by Microsoft and Apple... It's a shame they did not!

Having PKI is not a big deal. We get a certificates in France in 10 minutes
from the French Tax when we do our tax return online ! And you only need to
do it sometimes. You don't need a new certificate everyday !

You also need strong time synchronization to make it work but this is not a
big issue neither.

The only big problem is that neither Microsoft neither Apple implemented it.

Fred

Post by Jim Small
Karl,
http://en.wikipedia.org/wiki/Secure_Neighbor_Discovery_Protocol
http://ipv6.com/articles/research/Secure-Neighbor-Discovery.htm
Ideally I could point you to a Live CD but I couldn't find one. I'll ask
around and post back if I can find one. I know several people well who have
setup SeND with Linux/IOS so I know it's possible.
http://technet.microsoft.com/en-us/library/bb726956.aspx
Updated this August, from the Authorization for Automatically Assigned
Addresses and Configurations section, "Microsoft does not support SEND in any
version of Windows."
3) Definitive information on SeND support from Apple for OS X - unfortunately
I couldn't find it. I'll post back if I can.
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_sec
urity.html#wp1112987
--Jim
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

--
Fred Bovy
***@fredbovy.com
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013

Jim Small

2011-09-23 16:19:02 UTC

So is this Windows SeND solution a commercial solution, Open Source, or what?

--Jim

-----Original Message-----
From: ipv6hackers-***@lists.si6networks.com [mailto:ipv6hackers-***@lists.si6networks.com] On Behalf Of Sara
Sent: Friday, September 23, 2011 3:22 AM
To: IPv6 Hackers Mailing List
Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011

Hi All,
we already implemented SEND for windows however we're working on performance. I'm really interested to know more about CISCO implementation and other details if available because we would like to know what CISCO did about router certification and so on.

Regards,
Sara

________________________________
From: fred <***@fredbovy.com>
To: IPv6 Hackers Mailing List <***@lists.si6networks.com>; Karl Auer <***@biplane.com.au>
Sent: Thursday, September 22, 2011 6:15 PM
Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011

Hi,

A bit more about SEND.
I was the CISCO IPv6 engineer who did the dev-test for SEND. I wrote the
test plan and all the TCL scripts to test it all and I also developed the
template to decode the protocol with the Cisco Internal tool...

I would have love to see Microsoft keeps its word and implements it in Vista
as I heard they will but once we (CISCO) developed it, then Microsoft did
not :-(

I wrote this post about SEND:
http://www.fastlaneus.com/blog/2011/08/30/secure-the-ipv6-network-access-wit
h-secure-neighbor-discovery-send-rfc3971-and-cga-rfc3972/

I believe that there would be no protocol safer than IPv6 if SEND was
implemented by Microsoft and Apple... It's a shame they did not!

Having PKI is not a big deal. We get a certificates in France in 10 minutes
from the French Tax when we do our tax return online ! And you only need to
do it sometimes. You don't need a new certificate everyday !

You also need strong time synchronization to make it work but this is not a
big issue neither.

The only big problem is that neither Microsoft neither Apple implemented it.

Fred

Post by Jim Small
Karl,
http://en.wikipedia.org/wiki/Secure_Neighbor_Discovery_Protocol
http://ipv6.com/articles/research/Secure-Neighbor-Discovery.htm
Ideally I could point you to a Live CD but I couldn't find one. I'll ask
around and post back if I can find one. I know several people well who have
setup SeND with Linux/IOS so I know it's possible.
http://technet.microsoft.com/en-us/library/bb726956.aspx
Updated this August, from the Authorization for Automatically Assigned
Addresses and Configurations section, "Microsoft does not support SEND in any
version of Windows."
3) Definitive information on SeND support from Apple for OS X - unfortunately
I couldn't find it. I'll post back if I can.
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_sec
urity.html#wp1112987
--Jim
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

--
Fred Bovy
***@fredbovy.com
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013

Sara

2011-09-23 18:36:24 UTC

It is not open source, but for improvements and testing and getting feedbacks , we would like to consult and communicate with people who are professional in this field or have valuable experience and knowledge.

http://en.wikipedia.org/wiki/Secure_Neighbor_Discovery_Protocol
we try to make it as a commercial product but everything depends on our institute too and their decision :)

________________________________
From: Jim Small <***@cdw.com>
To: IPv6 Hackers Mailing List <***@lists.si6networks.com>
Sent: Friday, September 23, 2011 5:19 PM
Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011

So is this Windows SeND solution a commercial solution, Open Source, or what?

--Jim

-----Original Message-----
From: ipv6hackers-***@lists.si6networks.com [mailto:ipv6hackers-***@lists.si6networks.com] On Behalf Of Sara
Sent: Friday, September 23, 2011 3:22 AM
To: IPv6 Hackers Mailing List
Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011

Hi All,
we already implemented SEND for windows however we're working on performance. I'm really interested to know more about CISCO implementation and other details if available because we would like to know what CISCO did about router certification and so on.

Regards,
Sara

________________________________
From: fred <***@fredbovy.com>
To: IPv6 Hackers Mailing List <***@lists.si6networks.com>; Karl Auer <***@biplane.com.au>
Sent: Thursday, September 22, 2011 6:15 PM
Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011

Hi,

A bit more about SEND.
I was the CISCO IPv6 engineer who did the dev-test for SEND. I wrote the
test plan and all the TCL scripts to test it all and I also developed the
template to decode the protocol with the Cisco Internal tool...

I would have love to see Microsoft keeps its word and implements it in Vista
as I heard they will but once we (CISCO) developed it, then Microsoft did
not :-(

I wrote this post about SEND:
http://www.fastlaneus.com/blog/2011/08/30/secure-the-ipv6-network-access-wit
h-secure-neighbor-discovery-send-rfc3971-and-cga-rfc3972/

I believe that there would be no protocol safer than IPv6 if SEND was
implemented by Microsoft and Apple... It's a shame they did not!

Having PKI is not a big deal. We get a certificates in France in 10 minutes
from the French Tax when we do our tax return online ! And you only need to
do it sometimes. You don't need a new certificate everyday !

You also need strong time synchronization to make it work but this is not a
big issue neither.

The only big problem is that neither Microsoft neither Apple implemented it.

Fred

Post by Jim Small
Karl,
http://en.wikipedia.org/wiki/Secure_Neighbor_Discovery_Protocol
http://ipv6.com/articles/research/Secure-Neighbor-Discovery.htm
Ideally I could point you to a Live CD but I couldn't find one. I'll ask
around and post back if I can find one. I know several people well who have
setup SeND with Linux/IOS so I know it's possible.
http://technet.microsoft.com/en-us/library/bb726956.aspx
Updated this August, from the Authorization for Automatically Assigned
Addresses and Configurations section, "Microsoft does not support SEND in any
version of Windows."
3) Definitive information on SeND support from Apple for OS X - unfortunately
I couldn't find it. I'll post back if I can.
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_sec
urity.html#wp1112987
--Jim
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

--
Fred Bovy
***@fredbovy.com
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013

_______________________________________________
Ipv6hackers mailing list
***@lists.si6networks.com
http://lists.si6networks.com/listinfo/ipv6hackers

Eric Vyncke (evyncke)

2011-09-26 12:48:38 UTC

Sara,

As you kindly asked about Cisco SeND implementation, here are some details:
- available since probably 2 years now in IOS (this is for the 'regular' routers not for the big ones)
- it obviously includes CGA
- RA can be protected as well but, of course, router must have a certificate (IOS router can be part of a PKI, from sending an enrollment request, checking CRL and even acting as poor-man CA) and the receiving nodes must have configured the trust anchor

I would be really interested to know more about your implementation because SeND in a router is a nice engineering work but as long as no nodes are able to process SeND-protected RA, it is also useless :-(

Hope this helps

-éric

Post by Jim Small
-----Original Message-----
Sent: vendredi 23 septembre 2011 09:22
To: IPv6 Hackers Mailing List
Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
Hi All,
we already implemented SEND for windows however we're working on
performance. I'm really interested to know more about CISCO implementation
and other details if available because we would like to know what CISCO did
about router certification and so on.
Regards,
Sara
________________________________
Sent: Thursday, September 22, 2011 6:15 PM
Subject: Re: [ipv6hackers] IPv6 security presentation at Hack.lu 2011
Hi,
A bit more about SEND.
I was the CISCO IPv6 engineer who did the dev-test for SEND. I wrote the
test plan and all the TCL scripts to test it all and I also developed the
template to decode the protocol with the Cisco Internal tool...
I would have love to see Microsoft keeps its word and implements it in Vista
as I heard they will but once we (CISCO) developed it, then Microsoft did
not :-(
http://www.fastlaneus.com/blog/2011/08/30/secure-the-ipv6-network-access-wit
h-secure-neighbor-discovery-send-rfc3971-and-cga-rfc3972/
I believe that there would be no protocol safer than IPv6 if SEND was
implemented by Microsoft and Apple... It's a shame they did not!
Having PKI is not a big deal. We get a certificates in France in 10 minutes
from the French Tax when we do our tax return online ! And you only need to
do it sometimes. You don't need a new certificate everyday !
You also need strong time synchronization to make it work but this is not a
big issue neither.
The only big problem is that neither Microsoft neither Apple implemented it.
Fred

have

Post by Jim Small
setup SeND with Linux/IOS so I know it's possible.
http://technet.microsoft.com/en-us/library/bb726956.aspx
Updated this August, from the Authorization for Automatically Assigned
Addresses and Configurations section, "Microsoft does not support SEND in

any

Post by Jim Small
version of Windows."
3) Definitive information on SeND support from Apple for OS X -

unfortunately

Post by Jim Small
I couldn't find it. I'll post back if I can.
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-

first_hop_sec

Post by Jim Small
urity.html#wp1112987
--Jim
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

fred

2011-09-22 20:47:59 UTC

Hi Joackim,

Yes I was aware that all the stateful devices can be the target of a DoS
attack

A DHCP server for instance is vulnerable to DoS attack as it is easy to
empty their pool by sending a lot of request and then keep their CPU very
busy to manage all the states.

For NAT also, we can see the same thing occuring.

But I was curious for a scenario where NAT can permit undetected MITM
attack. I can imagine how it is occuring actually because you are not seen
with your own address but with an address coming from a NAT pool. So there
is no way to identify the attacker with its address. But I was not aware of
such exploits... So any info providing more details about such exploit
interest me...

Thanks anyway.
Fred

Post by Joakim Aronius
All nodes that keep state are vulnerable to DoS. Arbor Networks published a
http://www.arbornetworks.com/report
Regards,
/joakim

_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

--
Fred Bovy
***@fredbovy.com
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013

fred

2011-09-22 21:00:58 UTC

I agree that SEND without Certificate does not help a lot!

And I remember having hit some issues running SEND without Certificate
during my testing. I don't remeber exactly what it was sorry long time ago.
But I would not recommend to do it...

Post by Fernando Gont
Eric,

Post by Eric Vyncke (evyncke)
Indeed, right to the spot: SEND per se works (and CGA does not
require PKI)

CGAs do not require a PKI. But if you don't use certificates, you don't
solve the problem of rogue routers, and hence you don't really get much
by using CGAs.
Thanks,

--
Fred Bovy
***@fredbovy.com
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013

Tomas Podermanski

2011-09-22 08:44:24 UTC

Hi all,
I see that slides turned on quite interesting discussion. I can also
contribute with two more presentation on that topic available at:

05/2011 IPv6 – Security Issues - IPSec does "solve" everything
http://europen.cz/Proceedings/38/2011-ipv6-sec-europen.ppt

09/2011 Deploying IPv6 in University Campus Network
http://ow.feide.no/_media/geantcampus:ipv6-podermanski.ppt
(starting slide 26 there are touched some issues that we feel them as
are very problematic - specially in a security area).

I will also be very glad to hear some comments or ideas related to the
topic and our points of view.

Thanks,
Tomas

Fernando Gont

2011-09-24 22:58:59 UTC

Hi, Tomas,

Post by Tomas Podermanski
Hi all,
I see that slides turned on quite interesting discussion. I can also
05/2011 IPv6 – Security Issues - IPSec does "solve" everything
http://europen.cz/Proceedings/38/2011-ipv6-sec-europen.ppt

Thanks for sharing the slides.

I went through this set (the one above), and must say I don't agree with
it. The reasons are those described in the slide set that I shared in
the first e-mail of this thread.

In short: There is not going to be any additional use of IPsec as a
result of IPv6 deployment. And not, there is not going to be increased
security with IPv6. Actually, at least in the short and near term, it is
going to be the other way around.

Rather than making claims about "improved security", we should raise
awareness about IPv6 security challenges, such that they are mitigated,
and the security level of the involved networks does not *decrease*.

Thanks!

Best regards,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Tomas Podermanski

2011-09-26 08:57:16 UTC

Post by Fernando Gont
Hi, Tomas,

You probably got me wrong. The first slide only demonstrates the very
common opinion about IPv6 and IPSec. I completely agree with you that
IPSec is NOT the solution for security problems and IPv6 have got a lot
of other and bigger troubles. In reality that means IPv6 is NOT ready
for using in production environment and can not provide even similar
security level as IPv4 does.

Post by Fernando Gont
In short: There is not going to be any additional use of IPsec as a
result of IPv6 deployment. And not, there is not going to be increased
security with IPv6. Actually, at least in the short and near term, it is
going to be the other way around.
Rather than making claims about "improved security", we should raise
awareness about IPv6 security challenges, such that they are mitigated,
and the security level of the involved networks does not *decrease*.

Jim Small

2011-09-27 01:26:23 UTC

Post by Fernando Gont
Rather than making claims about "improved security", we should raise
awareness about IPv6 security challenges, such that they are mitigated,
and the security level of the involved networks does not *decrease*.

Sure. I try to convince people in every my presentation that IPv6
doesn't bring any security benefits (instead of sites like ipv6.com).
The problem is that IPv6 protagonist do not want to hear such arguments
and always claims that is not too bad etc. As the result of that we can
see common IT staff very frustrated with IPv6 (Of course, I mean the
people who have started doing with IPv6). The sad reality that is just
impossible to properly secure a IPv6 network today. Even mitigation of
security problems with IPv6 will cost you fortune and still you will not
have an equivalent security level as in IPv4 - specially in first hop
security.

[JRS>] IPv6 brings many benefits and the potential for superior security to IPv4. The biggest challenge I see is that in order to achieve increased security all the vendors supporting IPv6 must choose to implement the enhanced security components. SeND is a perfect example. This would neatly solve many if not all of the issues with NDP spoofing. However, to the best of my knowledge it's not even in the mainline Linux/BSD kernels. Microsoft and Apple seem to have no interest in it. So while a solution is available and implemented by some (Cisco) unless all parties choose to implement it enhanced security will remain elusive. The same problem exists for mobility (MIPv6), multihoming (SHIM6), and other solutions (Location/Identity separation options). Any ideas on this?

--Jim

Owen DeLong

2011-09-27 01:28:41 UTC

I will point out that NDP spoofing is no worse than ARP spoofing in IPv4,
so, I'm not sure how you can say that it is not an equivalent level of first
hop security.

Owen

Post by Tomas Podermanski

Sure. I try to convince people in every my presentation that IPv6
doesn't bring any security benefits (instead of sites like ipv6.com).
The problem is that IPv6 protagonist do not want to hear such arguments
and always claims that is not too bad etc. As the result of that we can
see common IT staff very frustrated with IPv6 (Of course, I mean the
people who have started doing with IPv6). The sad reality that is just
impossible to properly secure a IPv6 network today. Even mitigation of
security problems with IPv6 will cost you fortune and still you will not
have an equivalent security level as in IPv4 - specially in first hop
security.
[JRS>] IPv6 brings many benefits and the potential for superior security to IPv4. The biggest challenge I see is that in order to achieve increased security all the vendors supporting IPv6 must choose to implement the enhanced security components. SeND is a perfect example. This would neatly solve many if not all of the issues with NDP spoofing. However, to the best of my knowledge it's not even in the mainline Linux/BSD kernels. Microsoft and Apple seem to have no interest in it. So while a solution is available and implemented by some (Cisco) unless all parties choose to implement it enhanced security will remain elusive. The same problem exists for mobility (MIPv6), multihoming (SHIM6), and other solutions (Location/Identity separation options). Any ideas on this?
--Jim
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Jim Small

2011-09-27 01:41:03 UTC

Owen,

I will point out that NDP spoofing is no worse than ARP spoofing in IPv4,
so, I'm not sure how you can say that it is not an equivalent level of first
hop security.
[JRS>] I believe I owe Fernando the credit for this, but my understanding of the difference is that you can't fragment ARP but you can fragment NDP. Since NDP is based on IPv6 instead a L2 protocol like ARP which rides on Ethernet or the L2 technology, you can fragment it and use this to bypass ACLs or RA Guard. AFAIK you can't do this with ARP. There are proposals to fix this, but as far as I know a solution has not yet been implemented.

--Jim

Marc Heuse

2011-09-27 08:06:52 UTC

Post by Owen DeLong
I will point out that NDP spoofing is no worse than ARP spoofing in IPv4,
so, I'm not sure how you can say that it is not an equivalent level of first
hop security.

comparing ARP with NA/NS - you are right.
But the RA are makeing the difference.

in IPv4 the router is configured by hand or comes from DHCP.
in IPv6 they can be configured by hand, but otherwise *must* come by RA,
as there is still no DHCP option for routes/routers.
You could argue that you can do DHCP spoofing too, yes, but only when a
device is asking for a new address or if you achieve the a little bit
more difficult part of sabotaging the renewing of a lease.
But with RA, an attacker can do that to all times to all systems.
And if autoconfiguration is active, you can configure DNS servers and
new routes at anytime to anybody too.

And that changes the threat level. As NDP consists of NS/NA and RS/RA,
the security is not equivalent. It would only be if you configure routes
manually on both IPv4 and IPV6.

Greets,
Marc

--
Marc Heuse
Mobil: +49 177 9611560
Fax: +49 30 37309726
www.mh-sec.de

Marc Heuse - IT-Security Consulting
Winsstr. 68
10405 Berlin

Ust.-Ident.-Nr.: DE244222388
PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A

Tomas Podermanski

2011-09-27 15:10:23 UTC

Hi,

Marc, thanks for explanation. I'd like to extend a little bit the
difference between IPv4 and IPv6 world. In IPv4 we know some techniques
to eliminate attacks as rouge DHCP server, ARP spoofing or address
spoofing. Many vendors implement DHCP snooping and some other
functionality (dynamic ARP protection/inspection, dynamic lock down/ip
source guard). All of them are based on simple idea - a database based
on the data from DHCP(v4) server (obtained during requesting IP address
from DHCP server). There is possibility to buy cheap access switches
supporting that features and you can easily have this level of security
on all access ports (if you want and need of course).

In IPv6 everything is differed. Addresses are not managed by a central
authority (aka DHCP server) but every node creates own address (at least
link local address). That means there is not possible to create similar
database to protect access ports. Some vendors tries to create such
database on combination of DHCPv6 + DAD packets (SAVI), but this still
not provide same level as IPv4 does.

The another problem is that only few devices devices supports IPv6
protection mechanisms for IPv6 (RA guard, ND protection, DHCPv6
snooping, SAVI*) today. All such devices are usually two or three times
more expensive comparing devices having protection for IPv4. What's
worse even if you have money to buy more expensive devices there are
still ways to bypass the protection (fragmented packets and extension
headers).

Building new network that will work for next 5 years we are faced with a
big dilemma. There are 3 possible scenarios:
1. Spent money on more expensive devices with IPv6 protection mechanisms
(that can by bypassed).
2. Save money and buy devices providing IPv4 only protection and block
all IPv6 traffic. It is not a good way to develop IPv6 by blocking them.
3. Save money and buy devices providing IPv4 only protection and monitor
ND packets (NDPmon etc.). It a way how we do it now, but it only
mitigates potential problem. Do not solve them and network is still
easily vulnerable.

It seems to me that the right solution ready to use does not exists yet.

Tomas

Post by Marc Heuse

Post by Owen DeLong
I will point out that NDP spoofing is no worse than ARP spoofing in IPv4,
so, I'm not sure how you can say that it is not an equivalent level of first
hop security.

comparing ARP with NA/NS - you are right.
But the RA are makeing the difference.
in IPv4 the router is configured by hand or comes from DHCP.
in IPv6 they can be configured by hand, but otherwise *must* come by RA,
as there is still no DHCP option for routes/routers.
You could argue that you can do DHCP spoofing too, yes, but only when a
device is asking for a new address or if you achieve the a little bit
more difficult part of sabotaging the renewing of a lease.
But with RA, an attacker can do that to all times to all systems.
And if autoconfiguration is active, you can configure DNS servers and
new routes at anytime to anybody too.
And that changes the threat level. As NDP consists of NS/NA and RS/RA,
the security is not equivalent. It would only be if you configure routes
manually on both IPv4 and IPV6.
Greets,
Marc
--
Marc Heuse
Mobil: +49 177 9611560
Fax: +49 30 37309726
www.mh-sec.de
Marc Heuse - IT-Security Consulting
Winsstr. 68
10405 Berlin
Ust.-Ident.-Nr.: DE244222388
PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Fernando Gont

2011-09-27 14:22:14 UTC

Post by Owen DeLong
I will point out that NDP spoofing is no worse than ARP spoofing in IPv4,
so, I'm not sure how you can say that it is not an equivalent level of first
hop security.

It's way easier to policy ARP traffic than it is to police NS/NA traffic.

The reason basically being described in:
<http://blog.si6networks.com/2011/09/router-advertisement-guard-ra-guard.html>

The contents of the aforementioned article also applies to NS/NA-based
attacks...

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Jim Small

2011-09-27 02:30:42 UTC

Tomas,

05/2011 IPv6 - Security Issues - IPSec does "solve" everything
http://europen.cz/Proceedings/38/2011-ipv6-sec-europen.ppt

09/2011 Deploying IPv6 in University Campus Network
http://ow.feide.no/_media/geantcampus:ipv6-podermanski.ppt
(starting slide 26 there are touched some issues that we feel them as
are very problematic - specially in a security area).
[JRS>] For problem 1, very nice write up and demonstration of the complexities/issues with address auto-configuration. For problem 2, impact on existing IPv4 infrastructure - for the most part this exists today. You can do ARP poisoning/spoofing and you can just as easily enable a rogue DHCPv4 server. The only real difference here is that because you can fragment NDP a malicious attacker is much harder to block. For someone accidentally enabling RAs/DHCPv6 this can be blocked with RA Guard/Port ACLs. For problem 3 - as has been discussed and shown there are solutions but the question remains will they be adopted/implemented? I do not agree with your conclusion for problem number 4. There are many benefits to IPv6. IPv4+NAT smothers innovation, especially for communications. It is ironic that the Internet was created for communication and yet IPv4+NAT makes this very difficult and requires 3rd party gateways. IPv6 restores this, at least partially by removing the need for NAT. For number 5 it really depends on who. Actually Cisco and Microsoft has excellent IPv6 VPN solutions. Cisco is closing in on feature parity between IPv4 and IPv6. Microsoft has also done fairly well in this regard. But you are correct in that some solutions/vendors have poor IPv6 support. For problem 6, privacy extensions can be disabled although this can be an issue for non-managed devices. I'm not sure what you mean by Netflow - v9/IPFIX support IPv6. DHCPv6 does have issues to work through but I think you captured this in problem 1. NAT is its own topic but where you talk about the benefits (and there are some), you should also talk about the drawbacks which are just as numerous. IPv6 tends to result in more tunnels too, but this really isn't a new issue - these exist today in IPv4. I will say that on a decent sized network with IPv6 IPAM becomes a necessity. Problem 7 is an issue. I think it is likely IPv4 will disappear off the Internet in less than 10 years. However, within our intranets it will likely persist for a long time most likely out lasting all of us. :-) This is added complexity but I think it's unlikely a solution will emerge to eliminate it. Just like with AppleTalk, IPX, SNA, DECnet and other legacy protocols as long as it is needed it will persist. I do not agree with problem 8. Newer development languages abstract addressing. If you use the right development tools you will most likely be oblivious to the addressing system. This is really only an issue for network administrators and people who write device drivers and the like. I like the presentation overall and agree that we need to have frank discussions and push vendors to solve existing problems.

--Jim

Tomas Podermanski

2011-09-28 13:31:07 UTC

Jim,

thanks for comments. I made some to clarification/extension into text.

Post by Fernando Gont
Tomas,
05/2011 IPv6 - Security Issues - IPSec does "solve" everything
http://europen.cz/Proceedings/38/2011-ipv6-sec-europen.ppt
09/2011 Deploying IPv6 in University Campus Network
http://ow.feide.no/_media/geantcampus:ipv6-podermanski.ppt
(starting slide 26 there are touched some issues that we feel them as
are very problematic - specially in a security area).
[JRS>] For problem 1, very nice write up and demonstration of the complexities/issues with address auto-configuration.

Thanks :-)

Post by Fernando Gont
For problem 2, impact on existing IPv4 infrastructure - for the most part this exists today. You can do ARP poisoning/spoofing and you can just as easily enable a rogue DHCPv4 server. The only real difference here is that because you can fragment NDP a malicious attacker is much harder to block. For someone accidentally enabling RAs/DHCPv6 this can be blocked with RA Guard/Port ACLs.

Yes, we already discussed that before. There are some possibilities but
implementing them into either existing or new infrastructure is really
not a piece of cake.

Post by Fernando Gont
For problem 3 - as has been discussed and shown there are solutions but the question remains will they be adopted/implemented?

Sure.

Post by Fernando Gont
I do not agree with your conclusion for problem number 4. There are many benefits to IPv6. IPv4+NAT smothers innovation, especially for communications. It is ironic that the Internet was created for communication and yet IPv4+NAT makes this very difficult and requires 3rd party gateways. IPv6 restores this, at least partially by removing the need for NAT.

IT professionals have no doubt about need of IPv6. Unfortunately
ordinary users that are used to using common applications (web, FB,
skype, twitter, ip telephony) do not understand what is wrong with
current IPv4 network and why some changes are necessary. People who
decides about money are ordinary users as well and it is very difficult
do convince them that money spend on a IPv6 infrastructure will not be
wasted.

Post by Fernando Gont
For number 5 it really depends on who. Actually Cisco and Microsoft has excellent IPv6 VPN solutions. Cisco is closing in on feature parity between IPv4 and IPv6. Microsoft has also done fairly well in this regard. But you are correct in that some solutions/vendors have poor IPv6 support.

Right. VPN was just an example. There are problems not only with VPN.
Many vendors claims support for IPv6, but often only basic IPv6 features
are implemented. For example some routers supports BGP, but BGP+ is not
implemented. Just same story with multicast routing, VRRP, etc.

Post by Fernando Gont
For problem 6, privacy extensions can be disabled although this can be an issue for non-managed devices. I'm not sure what you mean by Netflow - v9/IPFIX support IPv6. DHCPv6 does have issues to work through but I think you captured this in problem 1. NAT is its own topic but where you talk about the benefits (and there are some), you should also talk about the drawbacks which are just as numerous. IPv6 tends to result in more tunnels too, but this really isn't a new issue - these exist today in IPv4. I will say that on a decent sized network with IPv6 IPAM becomes a necessity.

The basic problem with privacy extensions and netflow becomes when the
flow data are used for accounting purposes. The pure netflow data can
provide enough information due to address changes. The more detailed
description of the problem can be found in the following document
http://www.terena.org/activities/campus-bp/pdf/gn3-na3-t4-cbpd132.pdf
(based on collecting neighbor cache and extending flow data).

I agree with you comment about NAT. There no doubts that NAT has lot of
drawbacks.

The problem with tunnels is something new in IPv6 from my point of view.
Sure - tunnels/VPNs are common in IPv4 as well, but there is a big
difference. Tunnels like 6to4 and teredo are created automatically
without attention of users or administrators. But that problem can be
partially solved by deploying native IPv6 connectivity.

Post by Fernando Gont
Problem 7 is an issue. I think it is likely IPv4 will disappear off the Internet in less than 10 years. However, within our intranets it will likely persist for a long time most likely out lasting all of us. :-) This is added complexity but I think it's unlikely a solution will emerge to eliminate it. Just like with AppleTalk, IPX, SNA, DECnet and other legacy protocols as long as it is needed it will persist.

Right, that is matter of time. I thing less than 10 years is too
optimistic (considering that many enterprise vendors have not even think
about ipv6 :-) ). We will see in 10 years.

Post by Fernando Gont
I do not agree with problem 8. Newer development languages abstract addressing. If you use the right development tools you will most likely be oblivious to the addressing system. This is really only an issue for network administrators and people who write device drivers and the like. I like the presentation overall and agree that we need to have frank discussions and push vendors to solve existing problems.

Exactly - it is the only way how we can move forward with IPv6.

Thanks again for your comments.

Tomas

fred

2011-09-24 23:08:49 UTC

Actually the last time I have felt such a HUGE demand for education and
training was when we started to help the telcos and a few enterprises to
deploy MPLS in the very early 2000's.

They were so scared not to be able to manage and troubleshoot any problem!

I think that if MPLS Traffic Engineering did not meet the success it
deserved (at least in France) this is because even with training, it was
still scary for them.
This is kind of weird because the same SPs were deploying ATM in parallel!
Maybe the ATM vendors had better solutions to manage and troubleshoot ATM
than CISCO for MPLS-TE.

I think that if some IP folks resist to IPv6 and are fighting to keep IPv4
with more NAT this is for the same reasons!

I also agree about Security. They don't want to have networks less secure
with IPv6. And this will be challenging during the transition to IPv6 !

Also the Transition to IPv6 is also a very hot topic for anyone who wants to
start IPv6 whatever it is an enterrpise or a SP. There are many options and
many implication on security.

Post by Eric Vyncke (evyncke)
My point is that indeed organizations should move to IPv6 but this
must be planned with training, education, ...

My point was, essentially, that if you decide to deploy IPv6, this
should be planned with proper education, and consideration of the
security implications.

--
Fred Bovy
***@fredbovy.com
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013

fred

2011-09-27 02:33:27 UTC

I would then say that it is a bit more complicated to fool NDP than ARP
because of its more sophisticated FSM, NUD, and so on...

So why NDP could be worse than ARP ? Because it can advertise a default
router with a RA? If the answer is yes maybe there is a way (which I would
not recommend anyway) to stop the router from sending RA and configure the
end node from DHCPv6 or manually. Just like IPv4 would do.

Or is there anything else where NDP spoofing is worst than ARP spoofing ? I
would really think the opposite...

Fred

Post by Owen DeLong
I will point out that NDP spoofing is no worse than ARP spoofing in IPv4,
so, I'm not sure how you can say that it is not an equivalent level of first
hop security.
Owen

--
Fred Bovy
***@fredbovy.com
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013

Jim Small

2011-09-27 03:04:47 UTC

Fred,

So why NDP could be worse than ARP ?
[JRS>] Better and worse. Better in the sense that it has more features and flexibility. Worse in the sense that since it uses IPv6 it can use (abuse) extension headers to bypass current security mechanisms like ACLs and RA Guard.

Because it can advertise a default router with a RA? If the answer is yes maybe there is a way (which I would
not recommend anyway) to stop the router from sending RA and configure the
end node from DHCPv6 or manually. Just like IPv4 would do.
[JRS>] Currently DHCPv6 is not capable of provisioning a default gateway, it relies on SLAAC for this. So currently disabling SLAAC would prevent DHCPv6 from working.

Or is there anything else where NDP spoofing is worst than ARP spoofing ? I
would really think the opposite...
[JRS>] I think it will end up being superior, but first the issues with extension header abuse and getting mainstream vendors like Microsoft and Apple to implement SeND must be addressed.

--Jim

Enno Rey

2011-09-27 08:31:49 UTC

Hi,

Post by fred
I would then say that it is a bit more complicated to fool NDP than ARP
because of its more sophisticated FSM, NUD, and so on...
So why NDP could be worse than ARP ? Because it can advertise a default
router with a RA? If the answer is yes maybe there is a way (which I would
not recommend anyway) to stop the router from sending RA and configure the
end node from DHCPv6 or manually. Just like IPv4 would do.

nope. as DHCPv6 does (currently, and the respective IETF draft was discarded after v01) _not_ allow the distribution of a default router.
so a node just configured by means of DHCPv6 only will not be able to communicate outside its local-link space. [which can be a desired state, security-wise, but will probably seldom be desirable functionality-wise ;-)]

as for manual config, not sure if anybody here regards this as a viable way in the IPv6 world...

thanks

Enno

Post by fred
Or is there anything else where NDP spoofing is worst than ARP spoofing ? I
would really think the opposite...
Fred

Post by Owen DeLong
I will point out that NDP spoofing is no worse than ARP spoofing in IPv4,
so, I'm not sure how you can say that it is not an equivalent level of first
hop security.
Owen

--
Enno Rey

ERNW GmbH - Breslauer Str. 28 - 69124 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 174 3082474
PGP FP 055F B3F3 FE9D 71DD C0D5 444E C611 033E 3296 1CC1

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
=======================================================

Owen DeLong

2011-09-27 08:44:21 UTC

as for manual config, not sure if anybody here regards this as a viable way in the IPv6 world…

I generally manually configure all servers and use RA/SLAAC for most client
hosts. I think that manual configuration is not only viable in IPv6, but, is the
preferred method for configuring hosts which provide named services in most
cases.

Owen

Jim Small

2011-09-27 23:40:11 UTC

Post by Enno Rey

Post by Enno Rey
as for manual config, not sure if anybody here regards this as a viable way

in the IPv6 world...
I generally manually configure all servers and use RA/SLAAC for most client
hosts. I think that manual configuration is not only viable in IPv6, but, is the
preferred method for configuring hosts which provide named services in
most cases.

As we scale towards trillions of Internet nodes with business/organizations wanting to decrease operational costs I'm wondering if the servers should always be statically addressed idea should be revisited with IPv6. I have heard of some service providers using completely dynamic provisioning successfully.

--Jim

Owen DeLong

2011-09-28 05:36:09 UTC

Post by Enno Rey

Post by Enno Rey
as for manual config, not sure if anybody here regards this as a viable way

YMMV... I tried it for a brief time and went back to static. The return to static significantly
reduced my level of pain.

Owen

Tomas Podermanski

2011-09-27 13:48:10 UTC

Hi,

Post by Enno Rey
Hi,

nope. as DHCPv6 does (currently, and the respective IETF draft was discarded after v01) _not_ allow the distribution of a default router.

History of default route in DHCPv6 is a little bit complicated. There
was several attempts to put a default route option into DHCPv6.

draft-droms-dhc-dhcpv6-default-router-00, Expired in 2009 after
discussion in dhcpwg
(http://www.ietf.org/mail-archive/web/dhcwg/current/msg09715.html)
draft-dec-dhcpv6-route-option-05, Expired in 2011

and now is IETF working on draft-ietf-mif-dhcpv6-route-option-03 and it
seem that this one might be accepted (but who knows).

Even if that the draft would be proposed as a standard we will have to
wait for several years while vendors accept it. So today we can not
count on it and live with both SLAAC and DHCPv6.

Post by Enno Rey
so a node just configured by means of DHCPv6 only will not be able to communicate outside its local-link space. [which can be a desired state, security-wise, but will probably seldom be desirable functionality-wise ;-)]

Exactly - it is reality of reality these days. What worse DHCPv6 is not
supported by all platforms (Win XP, older version MAC OS, some Linux
distribution) so you have to run SLAAC for these platforms as well to
provide IPv6 connectivity to them.

Post by Enno Rey
as for manual config, not sure if anybody here regards this as a viable way in the IPv6 world...

It might be viable way for servers but not for 6000 users using own
equipment and differed operating systems.

thanks

Tomas

Fernando Gont

2011-09-27 14:17:38 UTC

Hi, Enno,

Post by Enno Rey
nope. as DHCPv6 does (currently, and the respective IETF draft was
discarded after v01) _not_ allow the distribution of a default
router. so a node just configured by means of DHCPv6 only will not be
able to communicate outside its local-link space. [which can be a
desired state, security-wise, but will probably seldom be desirable
functionality-wise ;-)]

I don't recall of the top of my head what was the rationale for
producing the standards this way, but at least in principle it looks
rather dumb.

Yeas ago, you couldn't rely *only* on SLAAC, since it didn't yet support
the RDNSS option (which is vital in most network deployments) -- even
with RDNSS now *specified*, it is still not widely deployed, and hence
you cannot rely on SLAAC alone.

OTOH, you cannot rely on DHCPv6 alone if you cannot get a default route
with it.

This basically means you must support both, even if you only need very
little of one of them.

Not very much following the KISS principle...

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

s***@nethelp.no

2011-09-27 15:03:52 UTC

I don't recall of the top of my head what was the rationale for
producing the standards this way, but at least in principle it looks
rather dumb.

Religion. "The router knows best", and should therefore always be
trusted to supply the default gateway. And the IPv6 high priests
have strongly rejected all attempts at producing sanity here :-(

Steinar Haug, Nethelp consulting, ***@nethelp.no

Douglas Otis

2011-09-27 19:09:02 UTC

Post by Fernando Gont
Hi, Enno,

...

Post by Fernando Gont
Yeas ago, you couldn't rely *only* on SLAAC, since it didn't yet
support the RDNSS option (which is vital in most network deployments)
-- even with RDNSS now *specified*, it is still not widely deployed,
and hence you cannot rely on SLAAC alone.
OTOH, you cannot rely on DHCPv6 alone if you cannot get a default
route with it.

DHCP is not needed when there is a desire to simplify the network
architecture. RFC5006 introduced RDNSS in 2007, and was upgraded to
standards track in 2010 where DNS Search Lists (DNSSL) option was also
included. It should also be noted a large IPv6 provider's CPE supported
the RDNSS option for years with their 6RD deployment. With SRV records
and DNSSL, there is also no need for service related information to be
published by DHCP either. Progress in simplification is being made with
Free.fr's deployment representing a sizable percentage of the world's
IPv6 of Internet access traffic.
See http://en.wikipedia.org/wiki/Free_%28ISP%29

http://tools.ietf.org/html/draft-ietf-csi-send-cert-10 can also answer
the question whether an RA is from an authorized device.

Real LAN based security remains possible with SeND, and eventually DANE
although this represents a dramatic change. This feature may be
obtained from router and switch providers. Hopefully, OS venders will
soon build upon this currently "expensive" option, but what is the true
cost of insecurity?

Compromising a LAN need not be immediate. IPv4 insecurity often
represents a race won by compromised systems that can afford to wait.
Once two systems become compromised, even switches become prone. When
their TCAM becomes full, fail-over will likely flood packets to all
ports when a match is not found. Hardware based security is not enough.

-Doug

Fernando Gont

2011-09-27 19:36:39 UTC

DHCP is not needed when there is a desire to simplify the network
architecture.

That depends on what you mean by "simplify", or *what* (specifically)
you want to simplify. e.g., DHCPv6 makes logging trivial. However,
SLAAC+Privacy Extensions makes it rather difficult (at least with
publicly available tools).

Post by Douglas Otis
RFC5006 introduced RDNSS in 2007, and was upgraded to
standards track in 2010 where DNS Search Lists (DNSSL) option was also
included. It should also be noted a large IPv6 provider's CPE supported
the RDNSS option for years with their 6RD deployment.

Last time I checked (1-2 years ago), neither Windows, nor any of the
open source OSes I was using supported RDNSS by default.

Post by Douglas Otis
Real LAN based security remains possible with SeND,

... if only one could deploy it for the general case.

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Jim Small

2011-09-27 23:36:06 UTC

DHCP is not needed when there is a desire to simplify the network
architecture.

Last time I checked (1-2 years ago), neither Windows, nor any of the
open source OSes I was using supported RDNSS by default.

Here's a good list of RDNSS and DHCPv6 support for most O/S:
http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

Notably though OS X 10.7 supports it, along with some versions of UNIX/Linux. Crossing my fingers for Windows 8...

Post by Douglas Otis
Real LAN based security remains possible with SeND,

... if only one could deploy it for the general case.

Unfortunately I have no good news here. AFAIK it's not even in the stock BSD/Linux kernels and there is no option I know of for Apple/Microsoft O/S nor plans/interest from those vendors in supporting it.

--Jim

Fernando Gont

2011-09-28 00:17:19 UTC

Hi, Jim,

Post by Fernando Gont
Last time I checked (1-2 years ago), neither Windows, nor any of
the open source OSes I was using supported RDNSS by default.

http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems
Notably though OS X 10.7 supports it, along with some versions of
UNIX/Linux. Crossing my fingers for Windows 8...

Thanks for the info! -- I assume that the OS versions listed in the URL
above correspond to the first version of the OS which included support
for each feature... Skiming through the list, it seems that RDNSS
support was added to "latest version of X", which in most cases dates
back to only a few months ago.... Thus, I don't think one could rely on
support for such RDNSS, unfortunately.

-- not to mention that no version of Windows supports it... which in
most general scenarios makes this a "show stopper".

Post by Douglas Otis
Real LAN based security remains possible with SeND,

... if only one could deploy it for the general case.

Unfortunately I have no good news here. AFAIK it's not even in the
stock BSD/Linux kernels and there is no option I know of for
Apple/Microsoft O/S nor plans/interest from those vendors in
supporting it.

Even "implementation-wise" (i.e., even if SEND were deployable), it
would take years before OS versions with support for SEND replace
existing installations. -- That essentially mean that it would take many
years before you could actually think/try about deploying SEND.

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Douglas Otis

2011-09-28 02:08:12 UTC

On 9/27/11 5:17 PM, Fernando Gont wrote:

Hi Fernando,

Post by Fernando Gont
Hi, Jim,

Post by Fernando Gont
Last time I checked (1-2 years ago), neither Windows, nor any of
the open source OSes I was using supported RDNSS by default.

http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

Even this list missed a few as it is growing which should suggest there
might be trend...

Post by Jim Small
Notably though OS X 10.7 supports it, along with some versions of
UNIX/Linux. Crossing my fingers for Windows 8...

Thanks for the info! -- I assume that the OS versions listed in the URL
above correspond to the first version of the OS which included support
for each feature... Skiming through the list, it seems that RDNSS
support was added to "latest version of X", which in most cases dates
back to only a few months ago.... Thus, I don't think one could rely on
support for such RDNSS, unfortunately.
-- not to mention that no version of Windows supports it... which in
most general scenarios makes this a "show stopper".

Why continue to make extrapolation against IPv4 approaches where there
IS dependence upon both ARP and DHCP?

The point that must be internalized is that neither DHCPv6 nor RDNSS
reliance can be assumed. Neither protocol can act as a comprehensive
basis to identify hosts. Especially with limited support for relaying
and snooping host related information carried within DHCPv6 responses
that still will not identify a host in a meaningful way by the DUID.
The host must be extrapolated using non-standard inclusion host related
information added to logs. Why not leverage EAP related protocols
instead, for example? Leveraging a certificate assigned to a host is
far more secure and offers far greater security. It seems there are
several alternatives within the realm of being even more practical than
inventing yet another overly complex and painful DHCP arrangement.

Post by Douglas Otis
Real LAN based security remains possible with SeND,

... if only one could deploy it for the general case.

Unfortunately I have no good news here. AFAIK it's not even in the
stock BSD/Linux kernels and there is no option I know of for
Apple/Microsoft O/S nor plans/interest from those vendors in
supporting it.

Again, not all devices within a network would be required to support
SeND. See Configuring Secured and Nonsecured Neighbor Discovery Message
Coexistence Modes. As protocols like DANE get advanced, the need for
PKI related services start to disappear, which removes another
impediment against the use of SeND. Even DANE itself might act as a
replacement whenever encryption based upon the certificate at the host
is used.

It is hard to image how the typical arrangement used with IPv4 can be
trusted, especially with UDP packets being in the clear.

-Doug

Fernando Gont

2011-09-28 03:53:51 UTC

Hi, Douglas,

Post by Fernando Gont
Last time I checked (1-2 years ago), neither Windows, nor any of
the open source OSes I was using supported RDNSS by default.

http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

Even this list missed a few as it is growing which should suggest there
might be trend...

I've just checked a default installation of FreeBSD-current of a few
months ago, and it doesn't seem to be processing RDNSS. Could you please
comment on which version of FreeBSD you were referring to as "supporting
RDNSS"?

Post by Jim Small
Notably though OS X 10.7 supports it, along with some versions of
UNIX/Linux. Crossing my fingers for Windows 8...

Thanks for the info! -- I assume that the OS versions listed in the URL
above correspond to the first version of the OS which included support
for each feature... Skiming through the list, it seems that RDNSS
support was added to "latest version of X", which in most cases dates
back to only a few months ago.... Thus, I don't think one could rely on
support for such RDNSS, unfortunately.
-- not to mention that no version of Windows supports it... which in
most general scenarios makes this a "show stopper".

Why continue to make extrapolation against IPv4 approaches where there
IS dependence upon both ARP and DHCP?

My coments above where about RDNSS, and not about ARP, DHCP, SLAAC, or
DHCPv6.

However, since you asked, IPv4 depends on ARP for address resolution,
and on DHCPv4 for autoconfiguration (i.e., one protocol for one
function). IPv6 ends-up depending on SLAAC and DHCPv6 for
autoconfiguration (i.e., two protocols for a single function). --
(although strictly speaking, one should add MLD to that list).

Post by Douglas Otis
The point that must be internalized is that neither DHCPv6 nor RDNSS
reliance can be assumed.

Then comes the question: how the heck do we get the address of a caching
DNS server?

Post by Douglas Otis
Neither protocol can act as a comprehensive
basis to identify hosts. Especially with limited support for relaying
and snooping host related information carried within DHCPv6 responses
that still will not identify a host in a meaningful way by the DUID.

I don't follow. We're talking about how messy it is to be relying on two
protocols for the same function (autoconf), particularly when it would
be trivial to have SLAAC and DHCPv6 be independent from each other.

Post by Douglas Otis
The host must be extrapolated using non-standard inclusion host related
information added to logs. Why not leverage EAP related protocols
instead, for example? Leveraging a certificate assigned to a host is
far more secure and offers far greater security. It seems there are
several alternatives within the realm of being even more practical than
inventing yet another overly complex and painful DHCP arrangement.

Practicality aside (which is not generally the case for certificates),
the issue is probably that people simply want to "port" what they do in
IPv4 to IPv6.

Post by Fernando Gont
Even "implementation-wise" (i.e., even if SEND were deployable), it
would take years before OS versions with support for SEND replace
existing installations. -- That essentially mean that it would take many
years before you could actually think/try about deploying SEND.

Again, not all devices within a network would be required to support
SeND. See Configuring Secured and Nonsecured Neighbor Discovery Message
Coexistence Modes.

Last time I checked, that simply meant that SeND falls back to ND: i.e.,
if you don't implement SeND, you use ND.

But I don't follow what the argument is here...

Post by Douglas Otis
As protocols like DANE get advanced, the need for
PKI related services start to disappear, which removes another
impediment against the use of SeND. Even DANE itself might act as a
replacement whenever encryption based upon the certificate at the host
is used.

... and NATs will disappear with IPv6, and there will be increased use
of IPsec as a result of IPv6 end-to-end'ness, etc.

Jokes aside, we have been hearing theories (myths) of how great the
world is going to turn out. Let's just "downgrade" to a humble goal of
"longer addresses, with parity of features with IPv4".

Post by Douglas Otis
It is hard to image how the typical arrangement used with IPv4 can be
trusted, especially with UDP packets being in the clear.

Nobody said "trusted". We're just talking about how a number of
potential attacks can be mitigated. Basically, how to prevent trivial
DoS/MITM attacks.

Also, note that even if you have authentication at the link/internet
layers, you usually still need authentication at the user/app level,
which belongs way above the protocol stack.

For instance, SeND doesn't help much while the DNS is still mostly
insecure. Rather than bothering with ND spoofing or RA sppofing, an
attacker could simply spoof DNS responses. -- i.e., the usual "the
strength of a chain is that of its weakest link".

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Douglas Otis

2011-09-27 23:46:33 UTC

On 9/27/11 12:36 PM, Fernando Gont wrote:

Fernando,

Post by Fernando Gont
That depends on what you mean by "simplify", or *what* (specifically)
you want to simplify. e.g., DHCPv6 makes logging trivial. However,
SLAAC+Privacy Extensions makes it rather difficult (at least with
publicly available tools).

Cramming a growing list of options into DHCP packets has always stifled
innovation. Security obtained by injecting options into DHCP then
picked up via snooping is not without issues. This approach is neither
ideal or the simpler option. Especially when DHCP can no longer be
relied upon as being relied upon. Some systems may ignore RA
recommendations for stateful Address configuration, especial for devices
that do not support DHCPv6.

RFC5006 introduced RDNSS in 2007, and was upgraded to standards
track in 2010 where DNS Search Lists (DNSSL) option was also
included. It should also be noted a large IPv6 provider's CPE
supported the RDNSS option for years with their 6RD deployment.

Last time I checked (1-2 years ago), neither Windows, nor any of the
open source OSes I was using supported RDNSS by default.

Check again:

Cisco IOS, Fedora, HP-UX, iOS, OS X, MeeGo, Red Hat, Suse, Ubuntu, and
even FreeBSD (as of June 6) support RDNSS, as does Apple routers,
FreeBox, OpenWRT, etc.

Real LAN based security remains possible with SeND,

... if only one could deploy it for the general case.

Again, SeND does not require support by all devices. At least
deployment at the switch and router by either Cisco or Juniper offers
protection for an important portion of the infrastructure. Such use
also provides OS independent meansto identify rogue routers using Java
based SeND lite. :^)

How is security improved by allowing Windows or OS X to set standards at
the lowest denominator? Be bold. Parity with IPv4 is not good enough.

-Doug

Fernando Gont

2011-09-28 04:23:34 UTC

Cramming a growing list of options into DHCP packets has always stifled
innovation.

Innovation has been stifled by lack of ideas and protocol religion more
than by anything else.

Post by Douglas Otis
Security obtained by injecting options into DHCP then
picked up via snooping is not without issues.

Note sure what you mean.

Post by Douglas Otis
This approach is neither
ideal or the simpler option. Especially when DHCP can no longer be
relied upon as being relied upon. Some systems may ignore RA
recommendations for stateful Address configuration, especial for devices
that do not support DHCPv6.

I'm just arguing that it looks pretty dumb to have to different autoconf
methods that, at the end of the day, require support of the other --
yes, specification of RDNSS improves this on the SLAAC side, but...
specifying this after (almost) 10 years of RFC 2461 (now obsoleted by
RFC 4861) seems to be a hint that we should have done better.

Last time I checked (1-2 years ago), neither Windows, nor any of the
open source OSes I was using supported RDNSS by default.

Cisco IOS, Fedora, HP-UX, iOS, OS X, MeeGo, Red Hat, Suse, Ubuntu, and
even FreeBSD (as of June 6) support RDNSS, as does Apple routers,
FreeBox, OpenWRT, etc.

I will recheck Ubuntu and FreeBSD, but... do you mean this support is
"on" by default? i.e., do these implementations that ship with SLAAC
support "on by default" also have support for RDNSS "on by default"?

Real LAN based security remains possible with SeND,

... if only one could deploy it for the general case.

Again, SeND does not require support by all devices. At least
deployment at the switch and router by either Cisco or Juniper offers
protection for an important portion of the infrastructure.

Not sure what you mean. Say I have a local network, and want to protect
my network from ND spoofing and RA spoofing attacks, but hosts do not
support SeND. How do envision a scenario in which I'd benefit from SeND?

Post by Douglas Otis
Such use
also provides OS independent meansto identify rogue routers using Java
based SeND lite. :^)

:^)

With the current specs, that's probably as difficult as mitigating other
ND attacks.

Post by Douglas Otis
How is security improved by allowing Windows or OS X to set standards at
the lowest denominator?

Short answer: security improves in the same way it improves when we
produce standards that nobody implements and/or nobody deploys.

Another one could be:
Reality is... real. Even if you/me don't like that some vendor of set of
vendors don't implement this or that standard, from the pov of a
security guy that still means that something needs to be done to
mitigate existing vulnerabilities.

Some cynical might add:
How is security improved (in the first place) if one decides to opt for
vendors with questionable security-wise decisions or practices?

("practices" embracing anything from how they manage to vulnerabilities,
to which security features they decide to implement, or even whether the
source is publicly available or not....)

(And please note that I'm not referring to any particular vendor... but
rather pointing out that if one means to be really bold, then more
questions need to be asked (and probably first))

Post by Douglas Otis
Be bold. Parity with IPv4 is not good enough.

Probably. But... "96 more bits, no magic" is probably not good enough,
either (particularly after 25+ years of IPv4). However, at some point
one needs to be pragmatic: We'd all like some supercool protocol that
implements lots of supercool features and that is easy to transition to.
We don't have such a thing, and we need more addresses... hence we
deploy IPv6.

In the same way, we'd all like lots of cool security features that
everybody supports, and that are so easy to deploy and use. But we don't
have such thing, either. Hence we hope that, at the very least, we'll be
able to migrate our IPv4 techniques to IPv6 (which, at least, comes with
lots of years of experience).

That's probably what "engineering" is about.

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Erik Kline

2011-09-28 23:15:02 UTC

Post by Douglas Otis
Security obtained by injecting options into DHCP then
picked up via snooping is not without issues.

Note sure what you mean.

I didn't either, but I assumed it was a reference to the practice of access
layer gear (DSL, ...) inserting "subscriber line identifiers" into your DHCP
requests so that the DHCP server can tell which subscriber is asking and
return a custom result. There's the same thing for RS's as well, so that
the right RA can be determined and returned (unicasted to you).

But I could be totally mistaken.

Owen DeLong

2011-09-28 05:38:28 UTC

Post by Jim Small
Fernando,

Cramming a growing list of options into DHCP packets has always stifled innovation. Security obtained by injecting options into DHCP then picked up via snooping is not without issues. This approach is neither ideal or the simpler option. Especially when DHCP can no longer be relied upon as being relied upon. Some systems may ignore RA recommendations for stateful Address configuration, especial for devices that do not support DHCPv6.

There are already systems in IPv4 that ignore systems that are using addresses they weren't issued by the DHCP server. I see no reason such a system could not be put in place for IPv6 as well.

Owen

fred

2011-09-27 09:52:23 UTC

Thanks Jim,

I think I heard that DHCPv§ could not provision a default gateway but it
sounds so crazy that I immediately forgot this! Thanks...

I don't see any application where NDP would need extension headers...

Strictly NDP, not protocols running on ICMPv6 like MLD where you may need
the hop-by-hop extension with router alert bit. But NDP... I don't see...

Is there any NDP PDU which requires some Extension Header to work ?

If not may be we should start filtering out such packet, this should not be
a difficult rule to set in an ACL, and may be just not allow it in the
future... It there is no other application than hacking...

Or if there is an exception of an Extension header which may be useful, just
permit this one.

And I am 2000% with you than SEND MUST be implemented by Windows and MAC OS
X. It would make of IPv6 the safest protocol in the world...

Fred

Post by fred
Fred,
So why NDP could be worse than ARP ?
[JRS>] Better and worse. Better in the sense that it has more features and
flexibility. Worse in the sense that since it uses IPv6 it can use (abuse)
extension headers to bypass current security mechanisms like ACLs and RA
Guard.
Because it can advertise a default router with a RA? If the answer is yes
maybe there is a way (which I would
not recommend anyway) to stop the router from sending RA and configure the
end node from DHCPv6 or manually. Just like IPv4 would do.
[JRS>] Currently DHCPv6 is not capable of provisioning a default gateway, it
relies on SLAAC for this. So currently disabling SLAAC would prevent DHCPv6
from working.
Or is there anything else where NDP spoofing is worst than ARP spoofing ? I
would really think the opposite...
[JRS>] I think it will end up being superior, but first the issues with
extension header abuse and getting mainstream vendors like Microsoft and Apple
to implement SeND must be addressed.
--Jim
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

--
Fred Bovy
***@fredbovy.com
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013

fred

2011-09-27 10:51:55 UTC

You are right that the big issue with ND is that RA can be used announce a
Rogue router and without SEND or at least RA Guard, we have no way to
control this efficiently.

On the other hand, with IPv4 we had the ICMP REDIRECT since day 1 which has
the potential to do basically the same damage and reprogram the default
gateway of any host to an arbitrary address. And we have been living with
this threat for 30 years pretty good!

RA go a bit further as they can advertize much more than a default gateway.

But in IPv4 you can also have rogue DNS servers and rogue DHCP servers which
can break even more things than a rogue RA which can be identified very
quickly with a good IDS and blasted to stop its attack!

Fred

--
Fred Bovy
***@fredbovy.com
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013

Owen DeLong

2011-09-27 15:27:28 UTC

The key difference is that in IPv4, most of those mechanisms break things
visibly where a rogue RA can still forward the packets to the legitimate gateway
after capturing them.

Owen

Post by fred
You are right that the big issue with ND is that RA can be used announce a
Rogue router and without SEND or at least RA Guard, we have no way to
control this efficiently.
On the other hand, with IPv4 we had the ICMP REDIRECT since day 1 which has
the potential to do basically the same damage and reprogram the default
gateway of any host to an arbitrary address. And we have been living with
this threat for 30 years pretty good!
RA go a bit further as they can advertize much more than a default gateway.
But in IPv4 you can also have rogue DNS servers and rogue DHCP servers which
can break even more things than a rogue RA which can be identified very
quickly with a good IDS and blasted to stop its attack!
Fred

Marc Blanchet

2011-09-27 15:37:20 UTC

Post by Owen DeLong
The key difference is that in IPv4, most of those mechanisms break things
visibly where a rogue RA can still forward the packets to the legitimate gateway
after capturing them.

well, if I'm a rogue dhcpv4 server and advertise myself as v4 default router, then I can still "forward packets to the legitimate gateway after capturing them".

no?

Marc.

Post by Owen DeLong
Owen

_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Owen DeLong

2011-09-27 17:41:03 UTC

Post by Marc Blanchet

Post by Owen DeLong
The key difference is that in IPv4, most of those mechanisms break things
visibly where a rogue RA can still forward the packets to the legitimate gateway
after capturing them.

well, if I'm a rogue dhcpv4 server and advertise myself as v4 default router, then I can still "forward packets to the legitimate gateway after capturing them".
no?

Yes, but, your DHCP advertisements will likely conflict with the legitimate DHCP server's
leases, OR, you will have to NAT the packets as well which provides other forms of
breakage unless you also implement a suite of ALGs which provide yet another different
form of breakage.

Additionally, if anyone is paying any attention, the different address issue becomes
somewhat obvious.

Contrast this with rogue RA where the only bogus information is the default route
and you can easily and completely transparently forward the packets to the legitimate
router...

Owen

Post by Marc Blanchet
Marc.

Post by Owen DeLong
Owen

_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Jim Small

2011-09-27 18:34:09 UTC

Post by Owen DeLong
The key difference is that in IPv4, most of those mechanisms break things
visibly where a rogue RA can still forward the packets to the legitimate gateway
after capturing them.

well, if I'm a rogue dhcpv4 server and advertise myself as v4 default router, then I can still "forward packets to the legitimate gateway after capturing them".

[JRS> ] All of this can be done with IPv4. ARP poisoning is probably the easiest way to accomplish this and is rarely protected against. I believe the point is that in IPv4 for ARP spoofing/poisoning, DHCP spoofing, and spoofing in general we have excellent and reliable defenses such as ARP inspection/DAI, DHCP Snooping, and IP Source Guard. I believe Fernando has shown that the current defenses we have in IPv6 - Port ACLs and RA Guard can be bypassed by crafting and abusing specific extension headers. So, we need to push forward proposals to improve features like RA Guard, get DHCPv6 Snooping and IPv6 Source Guard, and consider limiting extension headers in NDP is they are not needed. This allows us to achieve "feature" or "security" parity with IPv4 in regards to this very specific set of features.

--Jim

fred

2011-09-28 10:29:07 UTC

Hi Fernando,

... and NATs will disappear with IPv6, and there will be increased use
of IPsec as a result of IPv6 end-to-end'ness, etc.

SNIP

Post by Fernando Gont
For instance, SeND doesn't help much while the DNS is still mostly
insecure. Rather than bothering with ND spoofing or RA sppofing, an
attacker could simply spoof DNS responses. -- i.e., the usual "the
strength of a chain is that of its weakest link".

This is exactly what I said about IPv4...

You can send an ICMP REDIRECT and change the routing of IPv4 end hosts to
any address ! You don't have to have IPv6 and RA do do that ! It seems that
everybody wake up on something which has already be there!

I also said that since day one we can also spoof DNS or DHCP response!
No need for RA to break a Network...

DNSSEC could help but I think it is not compatible with NAT.
And because it is a joke that NAT will disappear one day because people will
never realize that NAT brings much more troubles that it solves problems, we
are having a problem...

So, may be the best is solution may be to just do nothing... Just add some
more NAT as many people think it is the solution and consider that IPv6 was
just a bad idea, an illusion for naive people who thought that an address
for each device which need connectivity on the Internet would be the
solution. An illusion to think about all these applications which requires
direct connections rather than intermediate servers to bypass NAT...

--
Fred Bovy
***@fredbovy.com
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013

fred

2011-09-28 13:10:16 UTC

Just a last thing I would like to add about the spoofed RA!

These RA must be sent locally. RA must have a hop limit of 255 or it is
invalid!
For sure it may be easier to spoof a DNS answer but this is not a reason why
we don't use DNS with or without DNSSEC...

There is a long list of simple attacks (DoS, MITM,...) which can be done
from a local access, IPv4 or IPv6... A very long list! That's why we need
IDS to prevent all these attacks and neutralize the attacker...

Did we consider that it was a showstopper for IPv4 ?

Fred

Post by Jean-Michel Combes
Hi Fernando,

... and NATs will disappear with IPv6, and there will be increased use
of IPsec as a result of IPv6 end-to-end'ness, etc.

SNIP

This is exactly what I said about IPv4...
You can send an ICMP REDIRECT and change the routing of IPv4 end hosts to
any address ! You don't have to have IPv6 and RA do do that ! It seems that
everybody wake up on something which has already be there!
I also said that since day one we can also spoof DNS or DHCP response!
No need for RA to break a Network...
DNSSEC could help but I think it is not compatible with NAT.
And because it is a joke that NAT will disappear one day because people will
never realize that NAT brings much more troubles that it solves problems, we
are having a problem...
So, may be the best is solution may be to just do nothing... Just add some
more NAT as many people think it is the solution and consider that IPv6 was
just a bad idea, an illusion for naive people who thought that an address
for each device which need connectivity on the Internet would be the
solution. An illusion to think about all these applications which requires
direct connections rather than intermediate servers to bypass NAT...

--
Fred Bovy
***@fredbovy.com
Skype: fredericbovy
Mobile: +33676198206
Siret: 5221049000017
Twitter: http://twitter.com/#!/FredBovy
Blog: http://fredbovyipv6.blogspot.com/
ccie #3013

Fernando Gont

2011-09-29 05:32:33 UTC

Post by fred
There is a long list of simple attacks (DoS, MITM,...) which can be done
from a local access, IPv4 or IPv6... A very long list! That's why we need
IDS to prevent all these attacks and neutralize the attacker...

An IDS will do little in this case.

Post by fred
Did we consider that it was a showstopper for IPv4 ?

Nobody considered this a showstopper. We simply discussed the
aforementioned vulnerabilities, and tried to converge on the best
possible ways to mitigate them.

Bottom-line is that we need to get over the idea that discussing
drawbacks of or vulnerabilities in IPv6 makes us IPv6 heretics.

We really need to improve the current state of affairs of IPv6 security.
And that can only be achieved through increased awareness and community
efforts (.e.g, brainstorming on the best ways to mitigate
vulnerabilities, etc.)

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Owen DeLong

2011-09-29 08:48:03 UTC

An IDS will do little in this case.

Post by fred
Did we consider that it was a showstopper for IPv4 ?

Nobody considered this a showstopper. We simply discussed the
aforementioned vulnerabilities, and tried to converge on the best
possible ways to mitigate them.

Right.

Post by Fernando Gont
Bottom-line is that we need to get over the idea that discussing
drawbacks of or vulnerabilities in IPv6 makes us IPv6 heretics.

Agreed, but, to do that responsibly, we need to discuss them with
a reasonable tone. If the vulnerability in IPv6 isn't any worse than the
existing situation in IPv4, we should say that.

A lot of the IPv6 vulnerability stuff I see posted makes it sound like
deploying IPv6 will be the worst security disaster in the history of
the internet.

That's every bit as irresponsible as treating people like heretics
just for discussing vulnerabilities in IPv6.

Post by Fernando Gont
We really need to improve the current state of affairs of IPv6 security.
And that can only be achieved through increased awareness and community
efforts (.e.g, brainstorming on the best ways to mitigate
vulnerabilities, etc.)

We also really need to get IPv6 deployed in the real world and hysterics
about security issues that aren't any worse than IPv4 in actual fact are
quite counterproductive in this area.

There's a balance that needs to be struck and we really should make
some effort to be rational and factual in our tone when discussing such
vulnerabilities.

Owen

Fernando Gont

2011-09-29 15:30:50 UTC

Hi, Owen,

Post by Fernando Gont
Bottom-line is that we need to get over the idea that discussing
drawbacks of or vulnerabilities in IPv6 makes us IPv6 heretics.

Agreed, but, to do that responsibly, we need to discuss them with
a reasonable tone. If the vulnerability in IPv6 isn't any worse than the
existing situation in IPv4, we should say that.

The situation with IPv6, in general, is much worse than with IPv4. The
reasons are summarized in slide 6 of
<http://www.si6networks.com/presentations/hacklu2011/fgont-hacklu2011-ipv6-security.pdf>.

In particular, ND is much more complex than ARP, and hence there's much
more room for fail. The fact that that policing ARP is trivial, and that
RA-Guard implementations or monitoring tools such as NDPMon are so
trivial to evade should be a hint.

That said, rather than squelching discussion, we should probably support
efforts meant to improve the current state of affairs, such as those
linked in
<http://blog.si6networks.com/2011/09/router-advertisement-guard-ra-guard.html>

Post by Owen DeLong
A lot of the IPv6 vulnerability stuff I see posted makes it sound like
deploying IPv6 will be the worst security disaster in the history of
the internet.

It might be a disaster if people turn their look around, and pretend
that everything is just fine, when it isn't.

Post by Owen DeLong
That's every bit as irresponsible as treating people like heretics
just for discussing vulnerabilities in IPv6.

Me, I don't personally care about that. I've done the same sort of
security work for other protocols such as TCP and IPv4 (*). So if *I* am
taking as an IPv6 heretic, somebody doesn't get it. :-)

(*) See e.g.:
http://www.gont.com.ar/papers/index.html
http://www.gont.com.ar/drafts/index.html
http://www.gont.com.ar/rfcs/index.html

We also really need to get IPv6 deployed in the real world and hysterics
about security issues that aren't any worse than IPv4 in actual fact are
quite counterproductive in this area.

Aee above for a counter-argument. Me, I personally think that deploying
IPv6 without a careful understanding of the corresponding security
implications is simply insane.

Post by Owen DeLong
There's a balance that needs to be struck and we really should make
some effort to be rational and factual in our tone when discussing such
vulnerabilities.

I couple of days ago you were arguing e.g. that we're just fine if we
deploy RA-Guard. I'd personally fail one the other side: unless
something has been proven to be effective, it isn't.

Ignoring or neglecting security issues might be of some benefit for
envangelization purposes, but is a non-starter for a technical community.

Thanks,

--
Fernando Gont
SI6 Networks
e-mail: ***@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

Owen DeLong

2011-09-29 17:26:23 UTC

Post by Fernando Gont
Hi, Owen,

Post by Fernando Gont
Bottom-line is that we need to get over the idea that discussing
drawbacks of or vulnerabilities in IPv6 makes us IPv6 heretics.

Agreed, but, to do that responsibly, we need to discuss them with
a reasonable tone. If the vulnerability in IPv6 isn't any worse than the
existing situation in IPv4, we should say that.

The situation with IPv6, in general, is much worse than with IPv4. The
reasons are summarized in slide 6 of
<http://www.si6networks.com/presentations/hacklu2011/fgont-hacklu2011-ipv6-security.pdf>.

We can agree to disagree.

Post by Fernando Gont
In particular, ND is much more complex than ARP, and hence there's much
more room for fail. The fact that that policing ARP is trivial, and that
RA-Guard implementations or monitoring tools such as NDPMon are so
trivial to evade should be a hint.

The number of networks that even bother to police ARP in IPv4 being
relatively small leads me to believe that while you may be correct from
a technical puritanical perspective, in terms of real world vulnerability,
we have a long tradition of running insecure networks and that the IPv6
issues will get addressed in a similar manner to the IPv4 issues. As
someone exploits them dramatically, they'll get resolved or worked
around or otherwise mitigated.

Post by Fernando Gont
That said, rather than squelching discussion, we should probably support
efforts meant to improve the current state of affairs, such as those
linked in
<http://blog.si6networks.com/2011/09/router-advertisement-guard-ra-guard.html>

I was not advocating squelching discussion, but, I'm also not in favor
of hysterics. I still think that with RA guard, you're basically no worse
off than ARP in IPv4, just in slightly different ways.

Post by Owen DeLong
A lot of the IPv6 vulnerability stuff I see posted makes it sound like
deploying IPv6 will be the worst security disaster in the history of
the internet.

It might be a disaster if people turn their look around, and pretend
that everything is just fine, when it isn't.

I'm not convinced. We pretended everything was just fine with IPv4
for a long time. We continue to pretend everything is just fine with
IPv4 in many ways. The network still mostly works.

We also really need to get IPv6 deployed in the real world and hysterics
about security issues that aren't any worse than IPv4 in actual fact are
quite counterproductive in this area.

Aee above for a counter-argument. Me, I personally think that deploying
IPv6 without a careful understanding of the corresponding security
implications is simply insane.

I think insane is a somewhat strong term, but, I don't entirely disagree
with you here. However, I think that considering them requires a more
balanced evaluation of all of the factors, including the risks involved
in not deploying IPv6 which also are not small.

Post by Owen DeLong
There's a balance that needs to be struck and we really should make
some effort to be rational and factual in our tone when discussing such
vulnerabilities.

I couple of days ago you were arguing e.g. that we're just fine if we
deploy RA-Guard. I'd personally fail one the other side: unless
something has been proven to be effective, it isn't.

Proving my point that either extreme is useless. Those that are in favor
of IPv6 everywhere no matter what are ignoring the realities of the
need to address these security concerns.

Those claiming that these security concerns are significantly worse
than IPv4 and we should therefore put the internet on hold while
we figure it out are ignoring the risks associated with such an
action (the deployment of vastly larger amounts of CGN, the
destruction of any semblance of an IPv4 audit trail, the costs
associated with these various workarounds, etc.)

Bottom line, it's a tradeoff and focusing on any single issue is a
recipe for making bad choices.

Post by Fernando Gont
Ignoring or neglecting security issues might be of some benefit for
envangelization purposes, but is a non-starter for a technical community.

And yet the technical community has been operating the IPv4 internet
largely ignoring or neglecting security issues for decades.

I'm not advocating such behavior, but, I am pointing out that calling it a
non-starter is ludicrous in the face of the facts.

Owen

fred

2011-09-29 20:50:08 UTC

Hi Owen,

I read and read again and I am not sure I understand your point.

If you send a rogue ICMP Redirect to intercept the traffic.
So the source will use your IP address as the next hop instead of the
legitimate gateway, OK ?
Then you capture the packet and get the payload and then what prevent you
from forwarding the packet to the legitimate gateway ?

What is the difference with a rogue RA again ?

I must be stupid but I don't get your point here and it seems that I am
the only one on this list ;-)

TIA
Fred

Post by Owen DeLong
The key difference is that in IPv4, most of those mechanisms break things
visibly where a rogue RA can still forward the packets to the legitimate
gateway
after capturing them.
Owen

Post by fred
You are right that the big issue with ND is that RA can be used
announce a
Rogue router and without SEND or at least RA Guard, we have no way to
control this efficiently.
On the other hand, with IPv4 we had the ICMP REDIRECT since day 1 which
has
the potential to do basically the same damage and reprogram the default
gateway of any host to an arbitrary address. And we have been living
with
this threat for 30 years pretty good!
RA go a bit further as they can advertize much more than a default
gateway.
But in IPv4 you can also have rogue DNS servers and rogue DHCP servers
which
can break even more things than a rogue RA which can be identified very
quickly with a good IDS and blasted to stop its attack!
Fred

Post by fred
Fred,
So why NDP could be worse than ARP ?
[JRS>] Better and worse. Better in the sense that it has more
features and
flexibility. Worse in the sense that since it uses IPv6 it can use
(abuse)
extension headers to bypass current security mechanisms like ACLs and
RA
Guard.
Because it can advertise a default router with a RA? If the answer is
yes
maybe there is a way (which I would
not recommend anyway) to stop the router from sending RA and configure
the
end node from DHCPv6 or manually. Just like IPv4 would do.
[JRS>] Currently DHCPv6 is not capable of provisioning a default
gateway, it
relies on SLAAC for this. So currently disabling SLAAC would prevent
DHCPv6
from working.
Or is there anything else where NDP spoofing is worst than ARP
spoofing ? I
would really think the opposite...
[JRS>] I think it will end up being superior, but first the issues with
extension header abuse and getting mainstream vendors like Microsoft
and Apple
to implement SeND must be addressed.
--Jim
_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

_______________________________________________
Ipv6hackers mailing list
http://lists.si6networks.com/listinfo/ipv6hackers

Owen DeLong

2011-09-29 20:57:46 UTC