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 protected]> Subject: Re: secdir review of draft-ietf-sidr-origin-ops-22 To: Randy Bush <[email protected]> Cc: [email protected], [email protected], [email protected] Date: Tue, 19 Nov 2013 18:07:47 -0500 Randy Bush <[email protected]> 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 protected]> Subject: Re: secdir review of draft-ietf-sidr-origin-ops-22 To: Tom Yu <[email protected]> Cc: [email protected], [email protected], [email protected] 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 _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
