Subject: [OPSEC] comments on draft-ietf-opsec-lla-only-04

From: Jen Linkova <[email-masked]>
Date: Thu, 14 Nov 2013 18:22:53 +0100

Hello,

I've reviewed draft-ietf-opsec-lla-only-04, see my comments below.

1) 2.1.  The Approach

"Neither global IPv6 addresses nor unique local addresses are
   configured on infrastructure links.  "

[comment] Formally ULAs are of the global scope so maybe re-phrasing
to "neither globally routed addresses nor unique local addresses".

2) 2.1.  The Approach
" [RFC6724] mandates that greater than link-local scope IPv6 addresses
   must be used as the source IPv6 address for all generated ICMPv6
   messages sent to a non link-local address.
"

[comment] As I mentioned in Vancouver, I think this statement is not
absolutely accurate.
What RFC6724 mandates is that *if* candidate source addresses set
contains link-local and global addresses, then global address is
preferred for global destinations.
Therefore it is possible to chose link-local source for global
destination in some cases.
For example,  ND redirects MUST be sent from link-local address
(RFC4861, Section 4.5) while the destination may be global address.
Speaking of candidate set for DAS..
RFC6724 says:
"It is RECOMMENDED that the candidate source addresses be the set of
   unicast addresses assigned to the interface that will be used to send
   to the destination (the "outgoing" interface).  On routers, the
   candidate set MAY include unicast addresses assigned to any interface
   that forwards packets, subject to the restrictions described below.
   Implementations that wish to support the use of global source
   addresses assigned to a loopback interface MUST behave as if the
   loopback interface originates and forwards the packet."

Which means that it some implementations might not include lo0 into
the candidate set, in which case a router might use link-local as a
source which leads to operational issues and makes the troubleshooting
more difficult. I think it worth be discussed in the 'Caveats'
section.

3) 2.1.  The Approach
      "Control plane protocols, such as BGP [RFC4271], ISIS [IS-IS],
      OSPFv3 [RFC5340], RIPng [RFC2080], PIM [RFC4609] work by default
      or can be configured to work with link-local addresses.......
We therefore conclude that it is possible to construct a working
   network in this way."

[comment] However there are protocols which may experience issues in
such topology (RSVP). While you do mention RSVP later,  this section
discusses the effect on specific traffic types, so I'd suggest that
you add a sentence or two about protocols which might not work and
clarify that it is possible to construct a working network if those
protocols are not in use.

4) 2.1.  The Approach
"ICMP error message can be sourced from a loopback interface.  They
      must not be sourced from link-local addresses when the destination
      is non link-local."

See my comment #2 - applies here as well.

5) 2.2.  Advantages
[comment] If I were you, I'd reordered the paragraphs. IMHO, lower
configuration complexity & simpler DNS are the main advantages of the
suggested approach, then routing table reduction.
Reducing attack surface does not sound like a really big advantage
providing that risk can easily be mitigated - so probably it would
make sense to put it at the end of the section. What do you think?

"Lower configuration complexity: link-local addresses require no
   specific configuration, thereby lowering the complexity and size of
   router configurations.  This also reduces the likelihood of
   configuration mistakes."

[comment] I'd also mention that it simplifies the whole address
management process.

6)2.3. Caveats

"
Traceroute: similar to the ping case, a reply to a traceroute packet
   would come from the address of a loopback interface, and current
   implementations do not display the specific interface the packets
   came in on.  Also here, RFC5837 [RFC5837] provides a solution.
"

[comment] in the traceroute/ping section you are saying that RFC5837
provides a solution.
However there are two problems and only one might be solved by
including interface identifier into ICMPv6. The first problem is to
*see* which interface the packet arrived via. RFC5837 does help with
it. The second issue is that we are losing the ability to control the
path of the packet and specify which interface the traceroute/ping
packet should arrive on. It is especially useful for packet loss
troubleshooting. Would it be possible to clarify that RFC5837 provided
only partical solution?

7) 2.3. Caveats
"

Hardware dependency:.....
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"

[comment] I'd say that the complexity is higher as such approach
introduces an additional complexity in monitoring/troubleshooting.
Such configuration results in situation when an operator has to deal
with messages like 'BGP neighbor fe80::1%ae1 is down' which might be
confusing and requires additional efforts to identify neighbors. This
also applies to the next paragraph about NMS toolkit: an operator
needs to ensure that NMS and other tools support link-local addresses
not just for router interfaces but for protocol configuration (such as
BGP peers etc).

8) 2.4.  Internet Exchange Points
[comment] It would be great to see two subsection discussing
advantages and caveats like it is done above.

Typos found:

1)
1.  Introduction
s/OPSF/OSPF/

2)
2.3.  Caveats
s/implementions/implementations/

-- 
SY, Jen Linkova aka Furry

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 26 Nov 2013 10:06:53 +0000

Hello Jen

Thanks for your interest for our I-D and even more thanks for your valuable comments.

1) accepted

2) point taken for redirect message & use of loopback address being implementation dependent, we have modified this section

3) Control plane protocols, we now use 'Most control plane protocols' as RSVP is an exception ;-)

4) Same as 2) indeed

5) added that the order of advantage has no significance and added the 'Simpler address management' as suggestion (thanks)

6) good catch, traceroute text has been changed

7) static LLA configuration text has been modified

8) IXP, we preferred not to call out advantages and caveats as they previous ones also apply to IXP

Again big thanks

-éric

> -----Original Message-----
> From: Jen Linkova [mailto:[email-masked]]
> Sent: jeudi 14 novembre 2013 18:23
> To: opsec WG; Eric Vyncke (evyncke); Michael Behringer (mbehring)
> Subject: comments on draft-ietf-opsec-lla-only-04
> 
> Hello,
> 
> [comment] Formally ULAs are of the global scope so maybe re-phrasing to
> "neither globally routed addresses nor unique local addresses".
> 
> 
> 2) 2.1.  The Approach
> What RFC6724 mandates is that *if* candidate source addresses set contains
> link-local and global addresses, then global address is preferred for
> global destinations.
> Therefore it is possible to chose link-local source for global destination
> in some cases.
> For example,  ND redirects MUST be sent from link-local address (RFC4861,
> Section 4.5) while the destination may be global address.
> Which means that it some implementations might not include lo0 into the
> candidate set, in which case a router might use link-local as a source
> which leads to operational issues and makes the troubleshooting more
> difficult. I think it worth be discussed in the 'Caveats'
> section.
> 
> 3) 2.1.  The Approach
> [comment] However there are protocols which may experience issues in such
> topology (RSVP). While you do mention RSVP later,  this section discusses
> the effect on specific traffic types, so I'd suggest that you add a
> sentence or two about protocols which might not work and clarify that it
> is possible to construct a working network if those protocols are not in
> use.
> 
> 4) 2.1.  The Approach
> providing that risk can easily be mitigated - so probably it would make
> sense to put it at the end of the section. What do you think?
> 
> [comment] I'd also mention that it simplifies the whole address management
> process.
> 
> 6)2.3. Caveats
> 
> "
> However there are two problems and only one might be solved by including
> interface identifier into ICMPv6. The first problem is to
> *see* which interface the packet arrived via. RFC5837 does help with it.
> The second issue is that we are losing the ability to control the path of
> the packet and specify which interface the traceroute/ping packet should
> arrive on. It is especially useful for packet loss troubleshooting. Would
> it be possible to clarify that RFC5837 provided only partical solution?
> 
> 
> 7) 2.3. Caveats
> "
> 
> Such configuration results in situation when an operator has to deal with
> messages like 'BGP neighbor fe80::1%ae1 is down' which might be confusing
> and requires additional efforts to identify neighbors. This also applies
> to the next paragraph about NMS toolkit: an operator needs to ensure that
> NMS and other tools support link-local addresses not just for router
> interfaces but for protocol configuration (such as BGP peers etc).
> 
> [comment] It would be great to see two subsection discussing advantages
> and caveats like it is done above.
> 
> 
> Typos found:
> 
> 1)
> 1.  Introduction
> s/OPSF/OSPF/
> 
> 2)
> 2.3.  Caveats