Subject: Re: [sidr] New Version Notification for draft-ietf-sidr-origin-ops-23.txt

From: Randy Bush <[email-masked]>
Date: Thu, 21 Nov 2013 08:09:10 +0900

spin which covers all comments between last call and iesg review.  many
iesg, a few directorates, ...

one comment not covered from tom yu of security directorate.  not that i
disagreed with comment, i could not figure out what to usefully do.
tom's comment appended.  would love clue-by-four on how to best address
tom's comment.

randy

> A new version of I-D, draft-ietf-sidr-origin-ops-23.txt
> has been successfully submitted by Randy Bush and posted to the
> IETF repository.
> 
> Filename:	 draft-ietf-sidr-origin-ops
> Revision:	 23
> Title:		 RPKI-Based Origin Validation Operation
> Creation date:	 2013-11-21
> Group:		 sidr
> Number of pages: 12
> URL:             http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-23.txt
> Status:          http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops
> Htmlized:        http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-23
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-origin-ops-23
> 
> Abstract:
>    Deployment of RPKI-based BGP origin validation has many operational
>    considerations.  This document attempts to collect and present those
>    which are most critical.  It is expected to evolve as RPKI-based
>    origin validation continues to be deployed and the dynamics are
>    better understood.
> 
> 
>                                                                                   
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

--

From: Tom Yu <[email-masked]>
Subject: Re: secdir review of draft-ietf-sidr-origin-ops-22
To: Randy Bush <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Tue, 19 Nov 2013 18:07:47 -0500

Randy Bush <[email-masked]> 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.

--

From: Randy Bush <[email-masked]>
Subject: Re: secdir review of draft-ietf-sidr-origin-ops-22
To: Tom Yu <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Wed, 20 Nov 2013 12:37:36 +0900

> The scenario you describe above seems to be one of multiple cases
> 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