Appreciate these first set of comments. - merike
> On Oct 25, 2018, at 7:15 PM, Fernando Gont <[email protected]> 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: [email protected] > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > OPSEC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsec >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
