[OPSEC] Some feedback on draft-ietf-opsec-v6

[Fernando Gont <[e-mail]>]

Folks,

Here are my notes while re-reading the doc. My comments have typos,
questionable English grammar :-), and missing ("you might want to" ||
"please" || "I'd") all over the place (*please* keep that in mind :-) ).


p 4:
>    A common question is whether companies should use PI vs PA space
>    [RFC7381], but from a security perspective there is little
>    difference. 

expand acronym upon first usage.


p4:
> hence, for
>    large network, 

s/network/networks/


p4:
> That RFC also recognizes the
>    need for host tracking and lists several mechanisms of how this can
>    be accomlished in section 9.1 or by the data sources (Section 2.6.1)
>    section of this document.

This one seems hard to parse ("or by the data..")
also s/accomlished/accomplished/


p5:
>  [SCANNING]
>    shows that there are scientifically based mechanisms that make
>    scanning for IPv6 reachable nodes more realizable than expected; see
>    also [RFC7707].


IIRC, [SCANNING] talks about the structure of the network bits, rathr
than host bits. You might want to move this ref to the previous page
when discussing using the bits for geography, etc.


p5:
>    While in some unmanaged environments obfuscating addresses could be
>    considered a benefit; it is a better practice to ensure that
>    perimeter rules are actively 

These need not be ... XOR ... One could do both :-)


p5:
>    Unique Local Addresses (ULAs) RFC4193 [RFC4193] are intended for
>    scenarios where IP addresses are not globally reachable, despite
>    formally having global scope.  

I think this should be something like "..for scenarios where systems are
not..." (see s/IP addresses/systems/)


p5:
>  RFC4193 [RFC4193] states that if these addresses are
>    accidentally leaked outside of a site via routing or DNS, there is no
>    conflict with any other addresses.  However, it would be prudent to
>    consider ingress filtering packets with ULA source addresses or
>    egress filtering packets with ULA destination addresses at the domain
>    boundary.


Some might read this in the wrong way: like the lack of conflict my be
enough reason not to filter. Thing is that lack of conflict can be of
benefit if you merge to nets. But you should always filter on your
edge... otherwise e.g. your peer could get ULA packets to you.


p5:
>    ULAs are assigned within pseudo-random /48 prefixes created as
>    specified in RFC4193 [RFC4193].  They could be useful for
>    infrastructure hiding as described in RFC4864 [RFC4864].

Some people (well, "folk") in argentina :-) randomize the prefixes,
since otherwise they lead to hard-to-remember addresses. :-)
Additionally, given that 2001:db8::/16 cannot be used in practice (they
are dropped at nodes, and its impossible to override this), some folks
in ARG frequently use ULAs in e.g. virtual labs (and the corresponding
documetation).


p5:
While not wanting to get into "ula usage", they can be useful when:
* you have internal servers that should only be reachable by internal
nodes. This makes the border ACLs easier. And the addresses don't change
if your provider leases you a different prefix.

* you want to keep communication within the internal network going while
there's an outage with your provider. In that case your PA space would
time out, and if you don't use ULAs, you might loose commuunication
within your network.


Pge 6 and others:
>    RFC6164 [RFC6164] in section 5.1 documents the reasons why to use a
>    /127 for inter-router point-to-point links; notably, a /127 prevents
>    the ping-pong attack between routers not implementing correctly
>    RFC4443 [RFC4443].  The previous recommendation of RFC3627 [RFC3627]
>    has been obsoleted and marked Historic by RFC6547 [RFC6547])

If the ref is the rfc # within brakes, I would just include the
reference.. otherwise "RFCxxxx [RFCxxxx]" duplicastes stuf unnecessarily.



Section 2.1.3:
Might want to point out that, more importantly, /127s mitigate NCE
attacks for cases where the implementation does not e.g. limit the
number of entries in the "INCOMPLETE" state.



> 2.1.4.  Temporary Addresses - Privacy Extensions for SLAAC
> 
>    Normal stateless address autoconfiguration (SLAAC) relies on the
>    automatically generated EUI-64 address, which together with the /64
>    prefix makes up the global unique IPv6 address.  The EUI-64 address
>    is generated from the 48-bit MAC address.RFC8064 [RFC8064] specifies
>    another way than using EUI-64 while still keeping the same IID for
>    each network prefix; this allows SLAAC nodes to always have the same
>    stable IPv6 address on a specific network while having different IPv6
>    address on different networks.

EUI-64 is kind of legacy now. At least recent versions of modern OSes
use RFC7217. Besides RFC8064 formely recommends against EUI-64 and
recommends RFC7217. (the text would seem t suggest you can do either
eui64 or rfc7217.. but you shouldnt).


Pag 6:
> Privacy extension addresses a.k.a.
>    temporary addresses may help to mitigate the correlation of
>    activities of a node within the same network, and may also reduce the
>    attack exposure window.

It certainly does reduce the attack window, also such reduction might be
questionable (ie., there's plenty of time to attack an adress that
remains valid for one day)



p 7:
> When
>    [RFC8064] is available, the stable temporary address are probably a
>    good balance between privacy (among multiple networks) and security/
>    user attribution (within a network).

s/stable temporary/stable privacy/


p7:
>    Using privacy extension addresses prevents the operator from building
>    a priori host specific access control lists (ACLs).  It must be noted
>    that recent versions of Windows do not use the MAC address anymore to
>    build the stable address but use a mechanism similar to the one
>    described in [RFC7217], this also means that such an ACL cannot be
>    configured based solely on the MAC address of the nodes, diminishing
>    the value of such ACL.

At least some versions of windows used to generate a random token, and
use it for the IID. in that sense, addresses configured for the same NIC
for different prefixes wuld get the same IID (in contrast with rfc7217,
where the IID would eb different)


Section 2.1.6:
RFC7610 might eb of use here. I guess there's also somethign from SAVI-land?



p 9:
> 
>    A firewall or any edge device able to enforce the recommended order
>    and number of occurences of extension headers is recommended.

change the last instance of "recommended" to avoid repetition.



> 
> 2.2.3.  Fragment Header
> 
>    The fragment header is used by the source when it has to fragment
>    packets.  RFC7112 [RFC7112] and section 4.5 of RFC8200 [RFC8200]
>    explain why it is important to:
> 
>       firewall and security devices should drop first fragment not
>       containing an upper-layer header;
> 
>       destination nodes should discard first fragments not containing an
>       upper-layer header.
> 
>    Else, stateless filtering could be bypassed by an hostile party.
>    RFC6980 [RFC6980] applies the same rule to NDP and the RA-guard
>    function described in RFC6105 [RFC6105].

The first para seems to have something missing (kind of "nodes should
drop first fragments that do not contain the entire ipv6 header chain").

Note: RFC6980 bans fragmentation for ND altogether -- RFC7112 jsut says
that the first fragment must contain the entire EH chain. RFC7113 spells
out how to implement ra-guard to avoid circumvention.


P.S.: May send more as I keep reading...

Thanks!

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