Skip to main content

Last Call Review of draft-ietf-opsec-lla-only-07
review-ietf-opsec-lla-only-07-opsdir-lc-woolf-2014-04-03-00

Request Review of draft-ietf-opsec-lla-only
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-04-07
Requested 2014-03-28
Authors Michael H. Behringer , Éric Vyncke
Draft last updated 2014-04-03
Completed reviews Genart Last Call review of -07 by Peter E. Yee (diff)
Genart Telechat review of -10 by Peter E. Yee (diff)
Secdir Last Call review of -07 by Christopher Inacio (diff)
Opsdir Last Call review of -07 by Suzanne Woolf (diff)
Assignment Reviewer Suzanne Woolf
State Completed
Review review-ietf-opsec-lla-only-07-opsdir-lc-woolf-2014-04-03
Reviewed revision 07 (document currently at 11)
Result Has Issues
Completed 2014-04-03
review-ietf-opsec-lla-only-07-opsdir-lc-woolf-2014-04-03-00
Hi,

First-time reviewer here….given the level of interest in this draft in LC,
there's an abundance of material to work with.

Standard disclaimer applies: these remarks are intended primarily as guidance
to the Ops ADs, as part of the ops-dir effort to make sure there's been ops
review of everything going to the IESG, and are otherwise to be treated exactly
like any other LC/review comments.

I reviewed Appendix A of RFC 5706, but discovered many of the questions don't
really apply. This document is not standards track, and the answers to most of
the RFC 5706 questions are either implementation-dependent (router OS) or
specified elsewhere (such as usage of ULAs). A couple of the questions have
helped point to a suggestion though (see below).

I agree with the general tone of the LC comments on ietf at ietf.org, and some
I found in the opsec WG list archive, in that the major question about this
document is whether it adequately documents the practice it describes,
including that for the most part the practice in question appears to be
sub-optimal ("most expedient current practice for some use cases"?) I've tried
to approach it from the perspective of a network operator trying to determine
whether I want to use this technique in my network.

I'm struck by two limitations in particular:

* The only real advantage that seems to be claimed for using LLAs in this
manner for routers is in reducing the attack surface for attacks that rely on
sending packets from outside the network to router interfaces. (The rest seem
to be about simplicity/scalability but don't actually say so, and see below on
that.) While this may well be true, it sounds a bit like the corresponding
justifications for IPv4 NAT, which was an ex-post-facto rationalization-- the
original use case for IPv4 NAT was address scarcity, which doesn't apply for
IPv6. What would be the initial driver for a network operator to investigate
this configuration option, besides that global addresses may not actually be
necessary for all router interfaces?

* While the document has a list of caveats to go with the advantages, the only
use case specifically discussed is IXPs. This limits the usefulness of the
document in practical terms. For example, the stated advantage of reduced
routes to carry in the IGP seems only narrowly applicable, and there's no
discussion of how big a network might be before this isn't a negligible
concern. Obviously the network operator is the one who determines this in
practice, but actual guidance here is extremely thin.

From the record, it looks like the WG was strongly in favor of documenting this
practice without commenting on whether it was a good idea, but without use
cases, specific comments on scalability, or comments on existing deployment,
it's hard for this (admittedly rusty) network operator to get a lot of insight
beyond the flat statement that "We therefore conclude that it is possible to
construct a working network in this way." Obviously the question whether it's a
good idea could be answered "It depends," and there's nothing wrong with that,
but this document seems of limited help in determining "Depends on what?"

A suggestion, given both my own reaction to the document and the LC comments
I've seen so far:

1. Add a brief paragraph to the introduction on "systemic impacts", laying out
the sense from the LC comments that using LLAs in this way generally adds
complexity to debugging, may not scale well (addresses that are invisible to
your addressing plan and DNS but appear in running router debug and IGP tables
may not actually be an improvement over maintaining those), and may limit
interoperability in specific contexts (such as needing to debug across
operational boundaries/LL scope, by making  global/ULA addresses a special
case). These add up to "don't do it unless you're comfortable with the
implications," without dismissing the advantages if they're important to you.

2. Further comments on existing deployment: is anyone doing this today, and
what seems to be the use case that compels them?

Hopefully this would balance the concerns raised with the ambiguous
applicability of the document, reluctance to go back and re-tool it too
aggressively, and the sense that the document needs to be strengthened from the
perspective of operational impacts.

HTH,
Suzanne