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

[Merike Kaeo <[e-mail]>]

Appreciate these first set of comments.

- merike

> On Oct 25, 2018, at 7:15 PM, Fernando Gont <[e-mail]> wrote:
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> OPSEC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
>