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 protected] [mailto:[email protected]] On Behalf
> Of Warren Kumari
> Sent: Saturday, March 16, 2013 10:10 AM
> To: [email protected]; [email protected]
> Cc: Warren Kumari
> Subject: [OPSEC] Start of WGLC for draft-ietf-opsec-lla-only
>
> 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
>
>
> _______________________________________________
> OPSEC mailing list
> [email protected]
> 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.
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
