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

[Tom Yu <[e-mail]>]

Randy Bush <[e-mail]> writes:

> thanks for the review
>
>> There should probably be an example of the sort of privilege
>> escalation attacks that can result from incautious Local-Preference
>> attributes.
>
> 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?

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.

>> Section 5 mentions a block 10.0.666.0/24, which is somewhat
>> 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).

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?