Subject: [sidr] Fwd: Re: SIDR ReCharter - to capture/cover path validation work

From: Joel Halpern <[email-masked]>
Date: Wed, 09 Mar 2011 18:46:32 -0500

I sent Randy the text below.  He asked that I post it to the list.
He had a number of concerns, one of which I is addressed by adding the 
[partially].  I also added the [possibly] trying to follow the 
suggestion further.

I am not by any means wedded to this wording.  What I am looking to 
accomplish is to add just a bit of text before the requirements to 
indicate why we are trying to do this.  It is not normative.  It is not 
itself setting a requirement.

Yours,
Joel

-------- Original Message --------
Subject: Re: [sidr] SIDR ReCharter - to capture/cover path validation work
Date: Wed, 09 Mar 2011 13:46:28 -0500
From: Joel M. Halpern <[email-masked]>
To: Randy Bush <[email-masked]>

For the end of the Introduction:

The requirements described here focus on protecting the AS Path
information used in BGP.  This is [partially] motivated by the fact that 
an attacker who can modify AS Path information can mislead otherwise 
well-behaving AS; [possibly] inducing them to forward packets in 
improper or possibly even harmful fashions.

Yours,
Joel

---

From: Randy Bush <[email-masked]>
Date: Thu, 10 Mar 2011 09:12:56 +0900

> I sent Randy the text below.

not including the text in brackets

> information used in BGP.  This is [partially] motivated by the fact
> that an attacker who can modify AS Path information can mislead
> otherwise well-behaving AS; [possibly] inducing them to forward
> packets in improper or possibly even harmful fashions.

one wants to protect the entire NLRI, not just the AS-Path.  and the
intro currently says precisely that.  for reference, here is the current
intro

   RPKI-based Origin Validation ([I-D.ietf-sidr-pfx-validate]) provides
   a measure of resilience to accidental mis-origination of prefixes.
   But it provides neither cryptographic assurance (announcements are
   not signed), nor assurance of the AS Path of the announcement.

   This document describes requirements to be placed on a BGP security
   protocol, herein termed BGPsec, intended to rectify these gaps.

your paragraph drags intent in.  as we are unable to know intent, what
is the win here?

then it gets into data plane forwarding, which the draft very explicitly
avoids.  what is a 'proper' direction?  what is a 'harmful' direction?
i feel the ground opening a big hole under me.  again, what's the win?

as i can not know your intent <g>, i suspect you are trying to motivate
the requirements in a practical manner.  while this is an understandable
goal, doing so seems to drag in all sorts of issues that might better be
avoided.  which is why the current bit of intro, quoted above, is very
careful just to state it in terms of assurance.

can other folk help us here?

randy