Folks, As promised, here's my review of the aforementioned I-D:
* Section 1.: > We propose to configure neither globally routable IPv6 addresses nor > unique local addresses on infrastructure links of routers, wherever > possible. We recommend to use exclusively link-local addresses on > such links. If the document is meant as a discussion of pros and cons, this paragraph should probably be rephrased (since it's actually recommending the use of link-local (only)). * Section 2: > 2. Using Link-Local Address on Infrastructure Links > > This document proposes to use only link-local addresses (LLA) on all > router interfaces on infrastructure links. Same as above. * Section 2: > For an network operator there may be reasons to send > packets to an infrastructure link for certain monitoring tasks; many > of those tasks could also be handled differently, not requiring > routable address space on infrastructure links. Please elaborate, or provide references. * Section 2.1: > These link-local addresses SHOULD be hard-coded to prevent the change > of EUI-64 addresses when changing of MAC address (such as after > changing a network interface card). The need not. PLease see draft-ietf-6man-stable-privacy-addresses (under IETF LC, IIRC). * Section 2.1: > ICMPv6 [RFC4443] error messages (packet-too-big, time-exceeded...) > are required for routers, therefore a loopback interface must be > configured with an IPv6 address with a greater scope than link-local > (this will usually be a global scope). This greater than link-local > scope IPv6 address must be used as the source IPv6 address for all > generated ICMPv6 messages sent to a non link-local address and must > belong to the operator and be part of an announced prefix (with a > suitable prefix length) to avoid being dropped by other routers > implementing [RFC3704]. Does this happen auto-magically? i.e., would the ICMPv6 sending rules and source-address selection RFC agree that such address would be employed (particularly when it doesn't belong to the interface being employed to send the packet)? If it does, you should probably make this explicit and reference the aforementioned RFCs. If it doesn't, then this issue might deserve more text. * Section 2.1: Do most implementations allow the use of this kind of aliases for loopback? (I'm not arguin that they don't, but just asking). * Section 2.1: > o Control plane protocols, such as BGP, ISIS, OSPFv3, RIPng, PIM > work by default or can be configured to work with link-local > addresses. Please add informative references for each of these. Additionally, if they don't by default with link-local addresses (as you suggest), it might be useful to provide pointers to relvant documentation that describes how to do so (even if that's just a reference to the corresponding Cisco manual). * Section 2.1: > o Management plane traffic, such as SSH, Telnet, SNMP, ICMP echo > request ... can be addressed to loopback addresses of routers with > a greater than link-local scope address. mmm.. not sure what you mean. You meant that such traffic would be directed to the loopback alias you've created? If so, this seems to imply that the aforementioned router implements the Weak ES Model (see Section 3.3.4.1 of RFC 1122). If this doesn't happen automagically, this issue would require further thoughts/elaboration. > Router management can > also be done over out-of-band channels. Does this imply "dial up"? Something else? -- I believe this one (along with troubleshooting) is very important,and requires further elaboration. * Section 2.1: > o ICMP error message can be sourced from a loopback address. They > must not be sourced from link-local addresses when the destination > is non link-local. Same as above. Does this happen automagically? Does this comply with RFC 4443 and the source address selection RFCs? * Section 2.2: > Every routable address on a router > constitutes a potential attack point: a remote attacker can send > traffic to that address, for example a TCP SYN flood, or he can > intent SSH brute force password attacks. We have an RFC about SYN floods (authored by W. Eddy... although I don't recall the number of the top of my head) -- would be good to reference. * Section 2.2: > If a network only uses > loopback addresses for the routers, only those loopback addresses > need to be protected from outside the network. But, if you still need global addresses, and you still need to protect them, does the benefits of this approach outweigh the posible drawbacks (in the management/onitoring and troubleshooting space)? Section 2.2: > Reduced attack surface: Every routable address on a router > constitutes a potential attack point: a remote attacker can send > traffic to that address, for example a TCP SYN flood, or he can > intent SSH brute force password attacks. If a network only uses > loopback addresses for the routers, only those loopback addresses > need to be protected from outside the network. This may ease > protection measures, such as infrastructure access control lists. If > the addressing scheme is set up such that all link addresses and all > loopback addresses are aggregatable, and if the infrastructure access > list covers that entire aggregated space, then changing to link-local > addresses does not reduce the attack surface significantly. Throughout this apragrpah you seem to use "loopback addresses" as referring to the alias (with global scope) that you've added to the loopback interface. If that's the case, it might be could to rephrase the text or add a note about this, since one is mostly used to thing about ::1 or 127.0.0.0/8 when thinking about "loopback addresses". (Proably the correct term for this case would be "global addresses assigned to the loopback interfaces). * Section 2.2: > Lower configuration complexity: LLAs require no specific > configuration (except when they are statically configured), Note that earlier in this document you required these addresses to be statically configured (actually, "hardcoded"). BTW, I think this is the first instance of LLA... but the acronym was never expanded (yes, I do know it stands for link-local addresses). * Section 2.2: > thereby > lowering the complexity and size of router configurations. This also > reduces the likelihood of configuration mistakes. (Me thinking out loud) I'm not sure about this one... My take is that whatever makes a human deviate from what he's most used to will imply more mistakes. * Section 2.2: > Simpler DNS: Less routable address space in use also means less DNS > mappings to maintain. Are you meaning reverse mappings? Forward mappings? Both? * Section 2.3 (editorial): > interface identifier of the interface a packet was received on in the > ICMP response; it must be noted that there are little implemention of > this ICMP extension. s/little implemention/few implementations/ * Section 2.3: > Traceroute: Similar to the ping case, a reply to a traceroute packet > would come from a loopback address with a greater than link-local > address. As noted above, it'd probably clearrer to say ".. from a global address assigned to the loopback interface" * Section 2.3: > Hardware dependency: LLAs are usually EUI-64 based, hence, they > change when the MAC address is changed. This could pose problem in a > case where the routing neighbor must be configured explicitly (e.g. > BGP) and a line card needs to be physically replaced hence changing > the EUI-64 LLA and breaking the routing neighborship. But, LLAs can > be statically configured such as fe80::1 and fe80::2 which can be > used to configure any required static routing neighborship. This > static configuration is similar in complexity to statically > configured greater than link-local addresses, however, it is only > required where routing peers are explicitly configured. This problem is tackled by draft-ietf-6man-stable-privacy-addresses. * Section 2.4: > Also all the > loopback addresses on the IXP can be discovered by a potential > attacker by a simple traceroute; a generic attack is therefore still > possible, but it would require significantly more work. I haven't given this one much of a thought... but it looks that mapping such addresses would still be within the category of "trivial"... Thanks! Best regards, -- 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
