Subject: [OPSEC] Review of draft-ietf-opsec-lla-only-03

From: Fernando Gont <[email-masked]>
Date: Tue, 02 Apr 2013 21:26:25 -0300

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-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492