Subject: [OPSEC] Start of WGLC for draft-ietf-opsec-lla-only

From: Warren Kumari <[email-masked]>
Date: Sat, 16 Mar 2013 10:10:23 -0400

Dear OpSec WG,

This starts a Working Group Last Call for draft-ietf-opsec-lla-only.
Both authors have replied, stating that they do not know of any IPR associated with this draft.

The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/

Please review this draft to see if you think it is ready for publication and comments to the list, clearly stating your view.

This WGLC ends 3-April-2013 -- I have extended the period slightly to allow folk to travel home, decompress and still have time to review.

Thanks,
Warren Kumari
(as OpSec WG co-chair)

--
"I think perhaps the most important problem is that we are trying to understand the fundamental workings of the universe via a language devised for telling one another when the best fruit is." --Terry Prachett

---

From: "George, Wes" <[email-masked]>
Date: Mon, 25 Mar 2013 17:27:51 -0400

I've reviewed prior versions of this document so I took a look at this version. While it has improved, my fundamental concern remains: That I think it's overselling the benefits of using LLA in the core while downplaying alternate solutions (IGP passive) that provide much of the same benefit without the nasty operational side effects that come from trying to run a network with no "real" addresses on its interfaces.
Diagnostic tools like pings and traces, as well as more important things like PMTUD are brittle enough without advocating this practice for questionable benefit. Yes, you can configure a router to respond to ICMP via a routable loopback address. However, we've seen in early practice that people aren't even bothering with reverse DNS for IPv6 so that you can see what the path actually is in a trace, so relying on such configuration being properly implemented, let alone applied pervasively and consistently to make critical bits of infrastructure work seems risky. Now I have to ask whether the trace failed because the router isn't responding with the right interface, or because something's actually broken. I also have a hunch that this would expose a whole new crop of routing protocol next-hop bugs and assorted weirdness based on what (flawed) assumptions router vendors made about interface addressing and reachability when implementing.

That said - this is an informational document, so I'm less bothered by it being published than were it a BCP, but I still have misgivings with it being published as a WG draft as currently written, because I think it would erroneously be interpreted as IETF consensus that this is the "right" way to number a network for optimal security.
My concerns could be addressed by removing "we propose..." and "we recommend..." in section 1, because that would change the tone of the document to simply noting that such a configuration is possible and should work if it is appropriate for your network, instead of recommending it generically with few exceptions as it currently does. The draft should also focus specifically on advantages that are not possible to realize by simply putting the interfaces into passive mode in the IGP, because otherwise I would argue that is actually the more common and more flexible practice, and this solution is simply solving a problem that is already solved.

Some specific comments:

I fundamentally disagree with the assertion in section 2 as currently worded:
        "Routers typically do not
        need to be reached from nodes of the network, nor from outside the
        network."
I think I understand what you mean, but "reached from" is ambiguous, and downplays the importance of the text in section 2.1. I'd agree that routers typically don't need to be reachable for management, and other reachability can be constrained down to a few critical types of traffic, but routers that are completely unreachable are pretty uncommon outside of VPN networks where the added security by obscurity is beneficial.

2.1: I think the "musts" in this section should all be normative, i.e. MUST since this is critical to the proper operation of the network and implementation of this idea. Otherwise, the RFC2119 boilerplate is extraneous and should be removed, as there are no normative keywords used in this draft.

2.2 - as noted above, each of the claimed advantages are caveated with one or more alternate ways to accomplish the same benefit or to obviate the benefit provided. This does not make for a good argument in favor of implementing LLA only.

2.3 - in networks with heavy use of ECMP, having the loopback address respond to pings and traces means that vital information about *which* of multiple paths the traffic actually took is lost.
" Today this does not display the specific interface the
   packets came in on." -- disagree. In most routers, the receiving interface is the one that responds to traces. When it has a uniquely identifiable IP address, one can determine which interface this was.

Dynamic LLA has other issues:
- diagnostic pings across connected interfaces are harder to complete - instead of simply typing ping [address], one must now specify the exit interface, effectively doubling the commands required.
- diagnostic traceroutes are similarly harder because one must specify a routable source interface and destination.
- in large networks, most connected interfaces are numbered using a standard numbering scheme such that one can derive the address of the remote side by simply adding or subtracting 1 from the local IP address. Pings to the remote side when dynamic LLAs are used require determining the address to be pinged, either via a show interface on the remote side, or a show ipv6 neighbor on the local side, and may be more prone to operator-induced failure due to the fact that the addresses are not obviously similar to one another.
- because dynamic addresses are not present in the configuration, it is impossible to search for them to determine where a given address may be if it shows up in diagnostic information  (packet captures, traces, routing updates, etc). Statically-assigned addresses show up in configuration, meaning that simple tools like grepping a rancid config repository can find the router on which that address is located.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Warren Kumari
> Sent: Saturday, March 16, 2013 10:10 AM
> To: [email-masked]; [email-masked]
> Cc: Warren Kumari
> Subject: [OPSEC] Start of WGLC for draft-ietf-opsec-lla-only
>
> Dear OpSec WG,
>
> Please review this draft to see if you think it is ready for publication
> and comments to the list, clearly stating your view.
>
> This WGLC ends 3-April-2013 -- I have extended the period slightly to
> allow folk to travel home, decompress and still have time to review.
>
> Thanks,
> Warren Kumari
> (as OpSec WG co-chair)
>
>
>
> --
> "I think perhaps the most important problem is that we are trying to
> understand the fundamental workings of the universe via a language
> devised for telling one another when the best fruit is." --Terry
> Prachett
>
>
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.