Subject: [secdir] secdir review of draft-ietf-sidr-origin-ops-22

From: Tom Yu <[email-masked]>
Date: Mon, 18 Nov 2013 22:51:26 -0500

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Summary: Ready with nits.

The Security Considerations section appears to accurately document the
significant limitations of Route Origin Authorizations.

There should probably be an example of the sort of privilege
escalation attacks that can result from incautious Local-Preference
attributes.

Editorial:

In Section 4, "along with it's traffic engineering characteristic(s)",
change "it's" to "its".

Section 5 mentions a block 10.0.666.0/24, which is somewhat
distracting because that is not a valid IPv4 address block.

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Nov 2013 13:21:44 +0900

thanks for the review

> escalation attacks that can result from incautious Local-Preference

how about

   Local-Preference may be used to carry both the validity state of a
   prefix along with its traffic engineering (TE) characteristic(s).  It
   is likely that an operator already using Local-Preference will have
   to change policy so they can encode these two separate
   characteristics in the same BGP attribute without negative impact or
   opening privilege escalation attacks.  E.g. do not encode validation
   state in higher bits than used for TE.

or do we need to spell it out with a hammer?

> In Section 4, "along with it's traffic engineering characteristic(s)",

<blush>

> distracting because that is not a valid IPv4 address block.

it's meant to be clearly invalid.  the standard docco block could not be
used as it was not big enough for the example (ops will laugh at 666 but
freak out and rathole on a prefix longer than a /24).

again, thanks.

randy

---

From: Tom Yu <[email-masked]>
Date: Tue, 19 Nov 2013 18:07:47 -0500

> or do we need to spell it out with a hammer?

I'm not sure I fully understand the scenarios, but I'm not very
familiar with network operations.  On further reflection, the
paragraph you have written above greatly clarifies paragraph 6 of
Section 5 and should probably replace it.

The scenario you describe above seems to be one of multiple cases
described in Section 5.  Am I correct in understanding that there at
least the following two sorts of inadvertent Local-Preference
signaling that can occur when encoding policy information into
Local-Preference?

   (1) As you describe above, RPKI validity state can override TE
   characteristics, contrary to operator intentions and possibly
   creating a security exposure.  This can happen if RPKI validation
   state is encoded in higher bits than TE characteristics.

   (2) As described in paragraph 7 of Section 5, other policy metrics
   that depend on peer community signaling could override information
   about RPKI validity state, contrary to operator intentions and
   possibly creating a security exposure.  (I assume "peer community"
   here means external BGP peers?)

How about using something like the following text to replace the final
paragraph of Security Considerations?

   When simultaneously encoding RPKI validity state and other policy
   information into Local-Preference, operators should take care to
   avoid creating privilege escalation exposures through such an
   encoding scheme, as described in Section 5.  For example, RPKI
   validity state could inadvertently override other policy
   information such as traffic engineering preferences, or policy
   information computed based on signaling from external peers could
   inadvertently override RPKI validity state.

> freak out and rathole on a prefix longer than a /24).

I defer to your greater familiarity with what readers in the
operations community will find distracting.  (Now that I think about
it, a reasonable (if overly permissive) parsing of 10.0.666.0 would be
equivalent to 10.2.154.0.)

In the interest of consistency, I noticed that Section 3 uses a
different example block: 10.0.66.0/24; did you intend to also use
10.0.666.0/24 there?

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Nov 2013 12:37:36 +0900

> described in Section 5.

we have 42 ways to encode policy.  there are more knobs than an antique
hardware shop, and someone has asked for and used every one.  [ i view
this as a bug, not a feature, but i lost these battles many years ago ]

i feared trying to enumerate the traps, hence the simple warning.

perhaps what could help most is a once sentence definition of a
downgrade attack.

randy