Re: [OPSEC] [v6ops] New updated version of draft-vyncke-opsec-v6-01 (Operational Security Considerations for IPv6 Networks)

[Fernando Gont <[e-mail]>]

Hi, Eric (et al),

I think this document is filling an existing gap. Thanks for writing it!

I've begun to read your I-D. I'll be sending some feedback in batches,
since it will likely result in more timely feedback.

Abstract:
I wouldn't go as far as saying that "RFC 4942 describes the security
issues in the protocol".


Introduction:
The I-D says
  "Network Address and Port Translation [RFC3022] has lead
   to the common feeling that NATPT equals security and with IPv6 NATPT
   is no more needed."

A side effect of NATPT is that the *device* ends up operating as a
stateful firewall that only allows return traffic. I'd personally find
it challenging (?) to find a term for which one could claim "X equals
security" (since there are many aspects of security, which can hardly be
addressed by a single "device"). However, I'd note that there are
security properties in firewalls (which a NATPT ends up acting as, as a
side effect).

Regarding "IPv6 NATPT", I seem to recall that it already ships with Linux?


Nits:

Section 2.1.1:
"Once an address allocation has been assigned"

This doesn't seem to parse well.


Section 2.1.1:

You should probably clarify that, when talking about "manually
configured addresses", you're talking about devices (e.g. routers) that
typically have their addresses manually-configured, and *not*
encouraging manually-configured addresses in general devices.


Section 2.1.2:

I don't recall the details of the discussion regarding ULAs, but would
guess that some have probably argued that they may make troubleshooting
painful?


Section 2.1.3:

This section should probably reference draft-ietf-v6ops-v6nd-problems,
since using /112 also works as a workaround for buggy implementations
that fail to properly manage the Neighbor Cache. Some slideware I've
used recently (e.g. , ) might be of help, too.



Section 2.1.4:

This section should reference RFC4941 rather than RFC3041.

You may want to reference draft-gont-opsec-ipv6-host-scanning.

Nit: s/know/known/

This section says "Privacy addressing attempts to mitigate this threat".
However, privacy addresses are typically (*) configured *in addition* to
IEEE-derived IIDS -- hence they do not mitigate the host scanning
problem. draft-ietf-6man-stable-privacy-addresses does, since they are
meant to replace the IEEE-derived IIDs.

(*) with the notable exception of OpenBSD, which removes IEEE-derived
IIDs when privacy addresses are enabled.


This section says "While privacy
   addresses are truly generated randomly to protect against user
   tracking, but assuming that nodes use the EUI-64 format for global
   addressing, a list of expected pre-authorized host addresses can be
   generated."

I don't follow... for outgoing connections, hosts would employ privacy
addresses, so...



Section 2.2:

Nits: s/relied/relies/
s/not he/on the/


Section 2.2.1:

You should probably note the many reasons for which SEND is challenging
to deploy (PKI, not widely implemented, etc.)

Additionally, as noted in draft-ietf-6man-nd-extension-headers, if you
end up relying on fragmentation (which you shouldn't!), it could be
possible for an attacker to circumvent SEND.


Section 2.2.2:

You may want to look at/reference: draft-gont-opsec-dhcpv6-shield.


Section 2.2.3:

Nit: s/DOS/DoS/


Section 2.2.4:

The I-D says
  "However, several evasion techniques that circumvent the protection
   provided by RA Guard have surfaced.  A key challenge to this
   mitigation technique is introduced by IPv6 fragmentation."

Note that for existing implementations, you do not even need to use
fragmentation: these RA-Guard implementations simply expect the ICMPv6
to follow the fixed IPv6 header -- hence simply including any IPv6
extension header is enough to circumvent them.


[I-D.gont-6man-nd-extension-headers] should now be
[I-D.ietf-6man-nd-extension-headers] ;-)


Ok, 2:33 AM... more on this later.... ;-)

Cheers,
Fernando




On 07/18/2012 03:34 PM, Eric Vyncke (evyncke) wrote:
> We have posted a new version of our draft draft-vyncke-opsec-v6 at:
> 
> http://tools.ietf.org/html/draft-vyncke-opsec-v6-01
> 
>  
> 
> As usual comments are welcome, at Paris, comments were ‘yes this is
> required’. BTW, the intent is not to write 100’s of pages but rather
> document existing I-D and good practices.
> 
>  
> 
> Best regards
> 
>  
> 
> -merike, kk and éric
> 
>  
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
> 


-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492