Subject: Re: [sidr] bgpsec-reqs-00

From: Russ White <[email-masked]>
Date: Wed, 09 Feb 2011 12:42:07 -0500

>> 3.9 If a BGPsec design uses signed NLRIs, it need NOT handle multiple
>> NLRIs in a single UPDATE, given the impossibility of splitting a
>> signed message while preserving the signature.
>>
>> I'm not certain why this would be in a requirements document. Can
>> anyone explain how this directly relates to the security of BGP? IE,
>> what is the direct relationship between stating that packing is no
>> longer needed in BGP, and improving the security of BGP itself?
> 
> note the 'need not.'  it does not say 'must not'.  the point is that, if
> there is a signature over the bundled nlri, that signature can not
> survive the next bgp peer, who will unpack the nlris due to their
> routing policy not sending the whole bundle to their next peer.
> i.e. imagine R0 sends a bundle to its customer R1, and R1 selects some,
> but not all, routes from R0 and others from elsewhere to send to its
> customer, R2.

I understand the reasoning, but I'm not certain why this should be
addressed as a "requirement." I could see something saying, "any
proposed system should not decrease performance by x%," let people
discuss what x should be. To say that a specific mechanism that will
impact performance is acceptable as a "requirement," no matter what the
impact is, because the authors are convinced that it "won't hurt
anything," is presuming on the entire set of possible environments, and
putting the requirement in a "backwards" way.

Some other system may decrease performance in a different way, but the
WG is not open to discussing such tradeoffs the way this is currently
written.

>> 3.14 A BGPsec design MUST NOT require operators to reveal proprietary
>> data.  This includes peering, customer, and provider relationships, an
>> ISP's internal infrastructure, etc. Though it is understood that some
>> data are revealed to the savvy seeker by BGP, traceroute, etc. today.
>>
>> What sense does it make to say the only system which may be deployed
>> is one that protects information already publicly available? This is a
>> non-requirement, and must not be included in the requirements list.
> 
> this is an absolute from many operators.

It's an absolute must that information already revealed publicly in one
context not be revealed in another. Interesting...

It would be better to have an actual list here. I've asked, for years,
for specific instances --use cases-- where specific information should
not be revealed. Thus far, the only ones I've actually been given are,
"we don't want a peer to know we're breaking the contract we have with
them." I don't find these sorts of reasons convincing.

What a requirements document should have, it seems to me, is a list of
information that the operator community has determined cannot be
revealed and a reason for each one.

> [ and note that backup paths are not very visible in bgp or traceroute ]

Okay, so you're suggesting two things:

1. The list of the AS' a given AS is peered to should not be collated
into a conveniently available list. You expect people to be forced to
work for this information.

2. Backup connections should not be advertised unless they are used. In
other words, only connections through which prefixes are actually being
advertised should be collectable from the system at large.

> bottom line: when i recieve an update for prefix P with path D C B A, i
> want firm assurance that A passed P to B, B to C, C to D, and D to me.
> firm, verifiable, assurance.

The question that needs to be answered here is simple: Are you trying to
have verifiable proof for a court case, or are you trying to validate
that the destination given actually exists through the advertising peer
to the extent possible within the protocol itself.

To say that one thing is "more assured," than another is to assume the
answer to the question, "more assured in what terms?"

> that some database says that *some* prefixes are allowed from A to B to
> C to D to me does not mean *all* are.  there are vast differences in how
> different prefixes are handled by each hop on the route.  think peer,
> provider, customer relationships.

First, you're assuming that in this network:

A--B--C

A can verify the policy between B and C somehow for a specific prefix or
reachable destination. BGP simply isn't built this way.

Second, you're assuming that the only way to verify things on a per
prefix basis is by signing the updates. Making assumptions about a given
solution set within a requirements document is a "bad thing." Don't do it.

Explain the requirements, not the solution.

>> What does "proving the AS Path the update has traversed," prove,
>> precisely? Does receiving an update through a specific path prove
>> traffic sent to that destination will traverse the path listed?
> 
> no, see security section.  locking down the data plane is the next high
> mountain.  one at a time.

You've not explained what you mean when you say you want to "lock down"
the control plane. Again, what are you trying to prove? That an update
passed along a certain path? Does that provide you with policy
assurance? Does it prove the destination indicated exists and is
reachable along the path indicated? Does it prove packets transmitted to
the destination will follow this path? Or, again, are you mostly
interested in proving what a peer sent to you for contract enforcement?
These are all legitimate concerns, but you need to indicate which one
you're actually trying to address.

> of course if you have a solution which locks down both the control plane
> and the data plane, i *extremely eagerly* await your i-d.

It's called circuit switching, rather than packet switching.

>> Does receiving an update prove that all destinations listed are
>> reachable along the path listed? Does receiving an update prove that
>> every AS along that path has agreed to forward traffic transmitted to
>> the destination indicated?
> 
> yes, agreed to.  of course, we can not yet guarantee that they do not

Um, no it doesn't. Simply receiving an update does not prove it is
"within policy" for the receiver to send traffic along the path
specified to the destination specified. In fact, you can't prove this
unless you expose the peering pairwise policy of every connected pair of
AS' in the path. And you can't prove it unless you remove aggregation
from the routing system.

>> 4.3 Replay of BGP UPDATE messages need not be completely prevented,
>> but a BGPsec design MUST provide a mechanism to control the window of
>> exposure to replay attacks.
>>
>> Again, this is an assumption which I completely and totally disagree
>> with. What is the window size allowed in terms of time? Is it minutes,
>> hours, days, weeks, months, or years?
> 
> tunable, i hope.  i am not much worried about my research prefixes being
> replayed.  root name servers may be.

This isn't a requirement. Put a number in there, so we can discuss it.

> i will be in your area 8-12 feb.  glad to chat face to face.

I'm in RTP, not SJ.

:-)

Russ

---

From: Randy Bush <[email-masked]>
Date: Wed, 09 Feb 2011 18:41:16 -0800

hi russ,

> addressed as a "requirement."

once again, note the 'need not.'  it relaxing the nlri packing
requirement.  as such, it is probably wise to be in a requirements
statement, but is not itself a new requirement.

if pdus/attributes are signed (not a given), a signed pdu with multiple
nlris cannot be split into separate pdus.  since splitting is normal --
due to local policy or perhaps better routing advertisements for that
prefix but not others in the pdu -- it follows that a bgpsec speaker
cannot accept any advertisement where a signature covers more than one
prefix.

otherwise, it will become something such as, "a bgpsec receiver who gets
a message with a single signature over multiple nlris may have to
discard the signature if routing policy will separate the nlri before
sending them onward."  and i suspect that both you and i might find this
too prescriptive and detailed.

> I could see something saying, "any proposed system should not decrease
> performance by x%," let people discuss what x should be. To say that a
> specific mechanism that will impact performance is acceptable as a
> "requirement," no matter what the impact is, because the authors are
> convinced that it "won't hurt anything," is presuming on the entire
> set of possible environments, and putting the requirement in a
> "backwards" way.

relaxing nlri packing is not a performance issue.  it is that s-bgp was
broken in that it thought it could sign a packed pdu which had multiple
nlris, not thinking through that the next router would break apart the
nlris under local policy and thus break any aggregated signature.

> WG is not open to discussing such tradeoffs the way this is currently

red herring.  this is not about performance at all, but about security.

> context not be revealed in another. Interesting...

and common in the infosec world.  as an infosec geek just said to me,
saying it in another context can prove (in a loose sense, i presume)
that something is true.  see (for an otherwise appalling example) the us
military on wikileaks.

> them." I don't find these sorts of reasons convincing.

i have not heard that quote.  amusing stalking horse.  excuse if i
ignore it.

> revealed and a reason for each one.

sorry.  what was unclear about "This includes peering, customer, and
provider relationships, an ISP's internal infrastructure, etc.?"  it's
not our problem or prerogative; operators, who will choose to deploy or
not, have made their requirement clear.  is it really our prerogative to
tell the operators what and how they have to justify to us?

> work for this information.

indeed

> 2. Backup connections should not be advertised unless they are used.

nope.  i did not say that.  i said that backup paths are usualy not
visible in analyses of public routing data.  this is due to bgp's best
path choices not propagating the less-preffered paths, and preserves
today's properties.  bgp is one of the world's best information hiding
protocols :).

paths that are actually used are disclosed to the parties on that path
and to those to whom their policy *chooses* to leak the path.  operators
like this.  otoh, researchers trying to generate AS topology graphs from
public data hate this (see our paper in submission,
http://archive.psg.com/101216.TenLessons.pdf).

of course, the origin of a backup path is the same as that of a primary,
and likely the more widely propagated, path.  so the roa is the same.

> In other words, only connections through which prefixes are actually
> being advertised should be collectable from the system at large.

not should be.  are.  see endless research papers on bgp analyses based
on route views and ris.

> to the extent possible within the protocol itself.

"destination exists through the advertising peer" is a new and novel
phrasing.  i can see why it would be confusing.  it sure confuses me,
which i admit is a low bar.  can we stick to bgp annoucements, please?

> answer to the question, "more assured in what terms?"

sorry, i missed where i said "more assured."

> reachable destination. BGP simply isn't built this way.

no.  current bgp is not built this way.  if it was, we would not need to
discuss bgp-level security.  as to per-prefix verifiability, you may
want to look at what steve kent's s-bgp proposals were trying to
achieve.  though operationally broken, they were very much per-prefix.

> Explain the requirements, not the solution.

actually, the document does.  it is the conversation which has drifted a
bit

   4.2  A BGPsec design MUST enable the recipient of an UPDATE to
        formally determine that the UPDATE has traversed the AS path
        indicated in the UPADTE.  Note that this is more stringent than
        showing that the path is merely not impossible.

> you're actually trying to address.

how about something like "formally determine that the UPDATE has
traversed the AS path indicated in the UPADTE?"

> It's called circuit switching, rather than packet switching.

so we can move on and consider this a red herring for the nonce.

> specified to the destination specified. 

one does not send traffic along a path.  one sends it to a next hop.
and R0 receiving a bgp announcement of prefix P from R1 does indeed
state that it is "within policy" for R0 to send data toward P to R1.

> In fact, you can't prove this unless you expose the peering pairwise
> policy of every connected pair of AS' in the path. And you can't prove
> it unless you remove aggregation from the routing system.

actually, this is quite untrue.  this is still stuck in the peering
database model.  the hope is that BGPsec does not need to 'expose'
anyone's policies any more than bgp announcements do now.

folk may choose to inject aggregated prefixes *into* the routing system,
and we encourage them to do so.  but there is effectively no aggregation
*within* the inter-provider routing system.  see the actual measurements
discussed on nanog etc.

> This isn't a requirement. Put a number in there, so we can discuss it.

what is not clear about
  o needs vary, and
  o it should be tunable?

just for example, for my research prefixes, i am not much worried about
replay attacks, and would be happy with O(days).  i imagine root name
servers might s/days/hours/ but really should not speak for them.

>> i will be in your area 8-12 feb.  glad to chat face to face.

well, i am usually in tokyo, so do call when you come by and i can
wander over to the dreaded rappongi where the cisco offices are.  but,
this week, i am in sjc playing operator and architect working with
vendors on this very subject.  sorry we could not get together.  email
is not the best communication medium.

we now have route origin validation pretty much nailed down, the
documents are leaving sidr for the iesg, adn we have running code in
routers.  imiho, it would be really good to not go around these old
overly well-traveled negative circles and to finally move bgp as-path
security forward.  constructive work from you and others would be a real
step.  thanks.

randy

---

From: Russ White <[email-masked]>
Date: Wed, 09 Feb 2011 22:01:29 -0500

> statement, but is not itself a new requirement.

Once again, the requirement should be for no more than "x%" performance
hit, not specific implementation points.

> that something is true.  see (for an otherwise appalling example) the us

Sorry, I don't buy it.

> tell the operators what and how they have to justify to us?

Everything. Again, a list, with use cases to back the list up.

>> work for this information.

And somehow you expect making people work for it will make it more secure.

> today's properties.  bgp is one of the world's best information hiding

So you're saying that backup paths should be able to be hidden until
they are actually used? Can you put together a list of the specific
information you think needs to be hidden, and back it up with use cases?

> not should be.  are.  see endless research papers on bgp analyses based

So then list this as a requirement. It's something that many different
options can provide for, of course, not just S-BGP.

> which i admit is a low bar.  can we stick to bgp annoucements, please?

No, we cannot. BGP announces _something_. Are you trying to secure the
something, or are you trying to secure the announcements? These are two
completely different problems.

> sorry, i missed where i said "more assured."

You said so in your email.

> achieve.  though operationally broken, they were very much per-prefix.

So you are stating that what you are trying to add is that A can
validate the policy between B and C?

> actually, the document does.  it is the conversation which has drifted a

No, the document explains a solution, not requirements.

1. There is no list of information operators expect to be hidden.
2. There is no idea of an acceptable performance degradation.
3. There is no statement of what is you're actually trying to achieve.

>>> no, see security section.  locking down the data plane is the next high

To "lock down the data plane," there are only two options:

1. Circuit switching.
2. End to end encryption, which is outside the scope of BGP or any other
routing protocol.

> traversed the AS path indicated in the UPADTE?"

How about explaining what this proves?

> state that it is "within policy" for R0 to send data toward P to R1.

Exactly. So, again, what are you proving by showing what the policy
between two peers multiple hops away is?

> anyone's policies any more than bgp announcements do now.

Actually, it is quite true. Simply put, BGP doesn't contain the
information about more than connected policy; you can't secure
information you don't have. Further, as long as I can underclaim, or
aggregate legally to bury a prefix I don't want you to know about, you
can't prove anything about the path beyond the next immediate hop.

So, which is it --you can, or cannot validate anything beyond the next hop?

>> This isn't a requirement. Put a number in there, so we can discuss it.

Because that's not what the doc says. It says "replays are acceptable."
Again, put a number in there.

> security forward.  constructive work from you and others would be a real

When you are going the wrong way, the most constructive step you can
take is to turn around.

But this isn't about your modifications to S-BGP. You might have noticed
I've not mentioned any specific protocol modification _once_. This is
about a requirements document that is, essentially, specifying a
protocol, rather than specifying requirements. If you want to go down a
road, then let's figure out where it is we want to go, rather than just
plowing ahead on any random road, and hoping we get someplace useful.

Russ

---

From: Randy Bush <[email-masked]>
Date: Wed, 09 Feb 2011 21:00:58 -0800

> hit, not specific implementation points.

and once again, the nlri packing issue is not about performance at all.
it is about security, security, and security.  please actually read the
prior email.

>> that something is true.  see (for an otherwise appalling example) the us

not a problem.  you don't have to.

> Everything. Again, a list, with use cases to back the list up.

did that two emails ago.

> And somehow you expect making people work for it will make it more

yep.  that is the infosec model.  read previous email.

> information you think needs to be hidden, and back it up with use

no i am not.  read the paragraph you just quoted above.

> options can provide for, of course, not just S-BGP.

that bgp only advertises best path is in rfc 4271.  apologies that it is
not a reference in the draft.  we'll fix that in the next draft.

> completely different problems.

if the abstract does not make this clear enough, please suggest wording.

   This document describes requirements for a future BGP security
   protocol design to provide cryptographic assurance that the origin AS
   had the right to announce the prefix and to provide assurance of the
   AS Path of the announcement.

> You said so in your email.

not in the ascii.  perhaps in the ebcdic translation.

> validate the policy between B and C?

no.

> No, the document explains a solution, not requirements.

that is an assertion which is a bit hard to substantiate.

> 1. There is no list of information operators expect to be hidden.

   3.14  A BGPsec design MUST NOT require operators to reveal
         proprietary data.  This includes peering, customer, and
         provider relationships, an ISP's internal infrastructure, etc.
         Though it is understood that some data are revealed to the
         savvy seeker by BGP, traceroute, etc. today.

> 2. There is no idea of an acceptable performance degradation.

nope.  do you have a suggestion?

> 3. There is no statement of what is you're actually trying to achieve.

funny, most folk find the abstract and intro pretty clear on that.  but
if you have more complete wording, do send text.

> 2. End to end encryption, which is outside the scope of BGP or any other

i am not sure these are the only ways to do so.  but this is pretty
irrelevant as the draft pretty clearly says

   3.4   A BGPsec design need not prevent attacks on data plane traffic.
         It need not assure that the data plane even follows the control
         plane.

so what exactly is your point here?

> How about explaining what this proves?

i have tried.  sorry if it does not make it clear to you.

> When you are going the wrong way, the most constructive step you can

good advice.

bye.

randy

---

From: Russ Housley <[email-masked]>
Date: Thu, 10 Feb 2011 01:37:29 -0500

> information you think needs to be hidden, and back it up with use cases?

No.  I hear that it is not a requirement to disclose them ahead of time.  The ASes along the path just need to be able to determine that it is valid before it is accepted.

Russ

---

From: Russ White <[email-masked]>
Date: Thu, 10 Feb 2011 08:04:19 -0500

> No.  I hear that it is not a requirement to disclose them ahead of time.  The ASes along the path just need to be able to determine that it is valid before it is accepted.

Then why doesn't the "requirements document" actually state this?

Again, my argument has been, and still is, that the "requirements
document," as presented, isn't requirements. If this is a requirement,
then list it. I'm not arguing for any particular system, which is where
the argument always tends to flow, but only that a requirements document
actually list requirements.

The only thing I get out of reading this document is, "S-BGP is
acceptable and required."

Russ

---

From: Shane Amante <[email-masked]>
Date: Fri, 11 Feb 2011 08:51:17 -0700

Randy,

On Jan 30, 2011, at 20:40 MST, Randy Bush wrote:
>> 3.3 As cryptographic payloads and loading on routers are likely to
>> seriously increase, a BGPsec design may require use of new hardware.
>> It must be possible to build routers that do BGPsec with within
>> acceptable (to operators) bounds of cost and performance.
>> 
>> This should be left out of any requirements document, and various
>> proposed system compared based on their costs and deployment
>> difficulty.
> 
> i take your point.  the intent was that compatibility with current
> hardware abilities is not a requirement that this document imposes on a
> solution.  it is quite likely that provider routers will need crypto
> assist and more ram.  though one hope that the stub customer edge will
> not.

Whoa there.  I couldn't disagree more wrt the above.

First, let's start with the most fundamental question.  Why is it that routers MUST sign, pass around and verify _in-band_ in the control plane various contents/PDU's _within_ BGP?  Note my very careful use of the work _in-band_.  By that I mean inside the BGP session itself, not on a side-band channel like RPKI and/or IRR is used today.  While I have grave concerns over in-band signing & verification, I am [much] less concerned about the latter for several reasons.  With respect to in-band:
1)  I'm extremely concerned over dependencies of automatically "trusting" signed data in-band within the control plane and not being able to reach servers (RP's?) to verify the contents of the PDU's are legitimate.  At least with prefix-filters and/or AS_PATH filters, it's very easy for me to manually disable some or all filtering for particular destinations in order to, say, get reachability to servers (RP's) to verify the authenticity of data.
2)  Related to point #1, we really should go back to first principles ask ourselves if we're really intending to conflate the _transport_ method (BGP) with the requirement to verify the data _inside_ of BGP.  If so, what is the reason?  Is it solely for convenience, (because BGP transport is already there), or other reasons?
3)  I really, really don't like the idea of "will need crypto assist and more ram" on my RE/RP's for several reasons, namely:
    a)  It's one more set of variables that my already over-worked Capacity Planning and NOC groups need to keep track of and attempt to stay ahead of.
    b)  It's extremely costly to upgrade RE/RP's, because said RE/RP's are only available from one source -- equipment vendors.  And, the upgrade paths typically don't buy you much in terms of more CPU, etc., because vendors are obligated to source "established" components they know they'll be able to acquire for several years into the future.  And, worst of all, the cycle to get those RE/RP's into the network is extremely long when you start to consider the budgeting, testing of new code, physical installation, customer disruption during maintenance windows, etc.
... at least with respect to (b), if I were able to use offboard CPU (i.e.: Intel/AMD servers, like in the RPKI/IRR world), then I have a much larger selection of HW to choose from and I can upgrade those in the network much, much more quickly.

At least with respect to #1 and #2, I don't see any discussion of the above in the current draft (although maybe I missed it?).  But, IMHO, those are _fundamental_ requirements that need to be discussed among the WG.  Before touching on any of the other points in Russ White's e-mails in this thread, (which I agree with), I think it's important to get back to basics.

> and the operators with whom we discussed (note that i am an operator,
> not a vendor with a bad habit of speaking for operators) this thought
> that this needed to be said from both ends of the scale.  we did not
> want the future security constrained by a 7200, nor did we want an
> explosion in costs.  as dollars are the bottom line in our capitalist
> culture, constraining them seems quite reasonable.

It wasn't discussed with me.  :-)

-shane

---

From: Tony Tauber <[email-masked]>
Date: Fri, 11 Feb 2011 11:41:39 -0500

I'm also wondering on which provider routers Randy's seeing the need for
crypto and other HW upgrades.
If it's every router that carries full routes or terminates an external BGP
session, that can be a pretty big nut to swallow.

Why don't we work on getting someone on board with a working something
before getting down the garden path which leads people to throw up their
hands about non-starters and stuff.

Tony

On Fri, Feb 11, 2011 at 10:51 AM, Shane Amante <[email-masked]>wrote:

> First, let's start with the most fundamental question.  Why is it that
> routers MUST sign, pass around and verify _in-band_ in the control plane
> various contents/PDU's _within_ BGP?  Note my very careful use of the work
> _in-band_.  By that I mean inside the BGP session itself, not on a side-band
> channel like RPKI and/or IRR is used today.  While I have grave concerns
> over in-band signing & verification, I am [much] less concerned about the
> latter for several reasons.  With respect to in-band:
> 1)  I'm extremely concerned over dependencies of automatically "trusting"
> signed data in-band within the control plane and not being able to reach
> servers (RP's?) to verify the contents of the PDU's are legitimate.  At
> least with prefix-filters and/or AS_PATH filters, it's very easy for me to
> manually disable some or all filtering for particular destinations in order
> to, say, get reachability to servers (RP's) to verify the authenticity of
> data.
> 2)  Related to point #1, we really should go back to first principles ask
> ourselves if we're really intending to conflate the _transport_ method (BGP)
> with the requirement to verify the data _inside_ of BGP.  If so, what is the
> reason?  Is it solely for convenience, (because BGP transport is already
> there), or other reasons?
> 3)  I really, really don't like the idea of "will need crypto assist and
> more ram" on my RE/RP's for several reasons, namely:
>    a)  It's one more set of variables that my already over-worked Capacity
> Planning and NOC groups need to keep track of and attempt to stay ahead of.
>    b)  It's extremely costly to upgrade RE/RP's, because said RE/RP's are
> only available from one source -- equipment vendors.  And, the upgrade paths
> typically don't buy you much in terms of more CPU, etc., because vendors are
> obligated to source "established" components they know they'll be able to
> acquire for several years into the future.  And, worst of all, the cycle to
> get those RE/RP's into the network is extremely long when you start to
> consider the budgeting, testing of new code, physical installation, customer
> disruption during maintenance windows, etc.
> ... at least with respect to (b), if I were able to use offboard CPU (i.e.:
> Intel/AMD servers, like in the RPKI/IRR world), then I have a much larger
> selection of HW to choose from and I can upgrade those in the network much,
> much more quickly.
>
> At least with respect to #1 and #2, I don't see any discussion of the above
> in the current draft (although maybe I missed it?).  But, IMHO, those are
> _fundamental_ requirements that need to be discussed among the WG.  Before
> touching on any of the other points in Russ White's e-mails in this thread,
> (which I agree with), I think it's important to get back to basics.
>
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Russ White <[email-masked]>
Date: Fri, 11 Feb 2011 12:02:31 -0500

> hands about non-starters and stuff.

It would be _terrific_ to have a requirements document built and
supported on the provider side --possibly with some various government
folks (will they have different requirements? Don't know) thrown in for
good measure. I'd really prefer this to a vendor or research based set
of requirements to work from.

:-)

Russ

---

From: "Smith, Donald" <[email-masked]>
Date: Fri, 11 Feb 2011 10:21:08 -0700

(coffee != sleep) & (!coffee == sleep)
[email-masked] gcia

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Shane Amante
> Sent: Friday, February 11, 2011 8:51 AM
> To: Randy Bush
> Cc: [email-masked]; Russ White
> Subject: Re: [sidr] bgpsec-reqs-00
>
> Randy,
>
Adding crypto engines and more ram is going to be expensive not just from a hardware pov but from power and heat.
We (ISPs) budget those items too. If all of my routers suddenly needed 20% more of either of those its going to affect our bottom line (cost of transport goes up):)

> Whoa there.  I couldn't disagree more wrt the above.
I could disagree more but Shane does a pretty good job here of stating why this is an issue.
(thanks Shane).

>
> First, let's start with the most fundamental question.  Why
> is it that routers MUST sign, pass around and verify
> _in-band_ in the control plane various contents/PDU's
> _within_ BGP?  Note my very careful use of the work
> _in-band_.  By that I mean inside the BGP session itself, not
> on a side-band channel like RPKI and/or IRR is used today.
> While I have grave concerns over in-band signing &
> verification, I am [much] less concerned about the latter for
> several reasons.  With respect to in-band:
> 1)  I'm extremely concerned over dependencies of
> automatically "trusting" signed data in-band within the
> control plane and not being able to reach servers (RP's?) to
> verify the contents of the PDU's are legitimate.  At least
> with prefix-filters and/or AS_PATH filters, it's very easy
> for me to manually disable some or all filtering for
> particular destinations in order to, say, get reachability to
> servers (RP's) to verify the authenticity of data.

Route filters in many ISPs are created and validated nightly and pushed to routers if a filter change is needed.
That isn't usually done in real time. It is almost always done on COTS hardware (not on the router it's self).

> 2)  Related to point #1, we really should go back to first
> principles ask ourselves if we're really intending to
> conflate the _transport_ method (BGP) with the requirement to
> verify the data _inside_ of BGP.  If so, what is the reason?
> Is it solely for convenience, (because BGP transport is
> already there), or other reasons?
> 3)  I really, really don't like the idea of "will need crypto
> assist and more ram" on my RE/RP's for several reasons, namely:
>     a)  It's one more set of variables that my already
> over-worked Capacity Planning and NOC groups need to keep
> track of and attempt to stay ahead of.
>     b)  It's extremely costly to upgrade RE/RP's, because
> said RE/RP's are only available from one source -- equipment
> vendors.  And, the upgrade paths typically don't buy you much
> in terms of more CPU, etc., because vendors are obligated to
> source "established" components they know they'll be able to
> acquire for several years into the future.  And, worst of
> all, the cycle to get those RE/RP's into the network is
> extremely long when you start to consider the budgeting,
> testing of new code, physical installation, customer
> ... at least with respect to (b), if I were able to use
> offboard CPU (i.e.: Intel/AMD servers, like in the RPKI/IRR
> world), then I have a much larger selection of HW to choose
exactly!

> from and I can upgrade those in the network much, much more quickly.
>
> At least with respect to #1 and #2, I don't see any
> discussion of the above in the current draft (although maybe
> I missed it?).  But, IMHO, those are _fundamental_
> requirements that need to be discussed among the WG.  Before
> touching on any of the other points in Russ White's e-mails
> in this thread, (which I agree with), I think it's important
> to get back to basics.
>
>

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 11 Feb 2011 15:37:12 -0500

(no hats today!)

On Fri, Feb 11, 2011 at 10:51 AM, Shane Amante <[email-masked]> wrote:
> First, let's start with the most fundamental question.  Why is it that routers MUST sign, pass
> around and verify _in-band_ in the control plane various contents/PDU's _within_ BGP?  Note my
> very careful use of the work _in-band_.  By that I mean inside the BGP session itself, not on a

(note this probably strays a tad from 'requirements', I think there's
also some utlity coming from the RPKI that's NOT necesarily )
One way I looked at this was that if the router that originates a
route today slaps an ASN on, no one is the wiser as to where/what
originated the actual route. A router in the middle of AS701 can
announce a route origined AS7018... if you look closely the route
looks 'odd' but other than that it's all good. Signing, in the case of
origin validation, the route on the origin router (or from the origin
ASN border router(s) ) means that you can say with some certainty
that:
  1) the route was originated by the owner of the certificate for that ASN
  2) the owner of that ASN cert lost his/her private key :(

Hopefully it's more 1 than 2... and hopefully if 2, the owner CRL's
the cert 'quickly'. Regardless downstream ASN's can say: "Yes, I see
that route is origined by AS701, she signed the route for us, w00t!"

Ideally with origin-validation + prefix-lists and as-path filters you
have better assurance that the route you see is really from that
origin. With the addition of RPKI data you should be able to query the
IRR, join that against the RPKI and create a concise prefix-list that
doesn't include legacy data users never cleaned out :( For some period
of time the best part of this should be the RPKI data for use in
making the prefix-list stuff better/faster/cleaner.

I think what's also missed some in the discussions is that prefix-list
+ as-path filters (+ other things you already do as a provider to
protect yourself from naughty customer devices) will continue to live
on.

> side-band channel like RPKI and/or IRR is used today.  While I have grave concerns over in-band
> signing & verification, I am [much] less concerned about the latter for several reasons.  With
> respect to in-band:
>
> 1)  I'm extremely concerned over dependencies of automatically "trusting" signed data in-band
> within the control plane and not being able to reach servers (RP's?) to verify the contents of the
> PDU's are legitimate.  At least with prefix-filters and/or AS_PATH filters, it's very easy for me to
> manually disable some or all filtering for particular destinations in order to, say, get reachability to

The architecture should provide, or the design includes the provision,
to have the data as close to your router(s) as you think is relevant.
It also includes the ability to NOT validate, or decide to do nothing
with the validation state info. Additionally, the routers keep a local
cache of the data that the RPKI global system contains (minus some
skew perhaps)... In a fresh-boot scenario you most certainly won't
have rpki data to use, you'll just not-validate data from your
customers until you have that data. Keep in mind though that the RPKI
data has helped you to build prefix-list/as-path filters so hopefully
it's not all sunk :) you can accept what prefixes you should expect
from your customer(s) and pass those along as normal. Later, once
security-data is available to you, you can start verifying that the
announcements you see are valid.

some more discussion of cold-start is necessary, and some ideas in the
-ops doc(s) will be helpful surrounding this (cold-start) and
placement of caches inside a network. (outlining the tradeoffs of
distance from the router who needs to use the cache)

>
> 2)  Related to point #1, we really should go back to first principles ask ourselves if we're really
> intending to conflate the _transport_ method (BGP) with the requirement to verify the data
> _inside_ of BGP.  If so, what is the reason?  Is it solely for convenience, (because BGP transport
> is already there), or other reasons?

I think, that today you receive a route in BGP, you believe it's
proper and pass it on. you have no real way to tell if the route was
originated by the ASN in the first (last? right-most) AS hop, you have
no real assurance that the prefix-list you used to fllter the route is
actually correct, and you have no understanding of the path seen in
the as-path aside from what the text says. (see pilosov/kopella)

>    a)  It's one more set of variables that my already over-worked Capacity Planning and NOC
> groups need to keep track of and attempt to stay ahead of.
>    b)  It's extremely costly to upgrade RE/RP's, because said RE/RP's are only available from one
> source -- equipment vendors.  And, the upgrade paths typically don't buy you much in terms of
> more CPU, etc., because vendors are obligated to source "established" components they know
> they'll be able to acquire for several years into the future.  And, worst of all, the cycle to get those
> RE/RP's into the network is extremely long when you start to consider the budgeting, testing of
> new code, physical installation, customer disruption during maintenance windows, etc.
> ... at least with respect to (b), if I were able to use offboard CPU (i.e.: Intel/AMD servers, like in
> the RPKI/IRR world), then I have a much larger selection of HW to choose from and I can
> upgrade those in the network much, much more quickly.

Some of the 'more ram, 64-bit os, faster-cpu, crypto-offload'
non-worry for me was that both large vendors stated:
  "We are working toward 64-bit OS, ability to have much more RAM on
board and faster CPU's. If you think crypto-offload is helpful, we can
add that as well in the right rev of device/card/etc"

I am under the impression that if we believe the ability of SIDR
output (rpki + protocol changes) to be used in ~7-10 years, I think we
made this timeline based on normal cycle times for routers in larger
networks. I hope that in the next rev or so of gear everyone buys
we'll see capacity for RAM increase, crypto-help (* if necessary) and
faster/more cpu. I believe both large vendors are on track to provide
64-bit OS's soonish as well.

> At least with respect to #1 and #2, I don't see any discussion of the above in the current draft
> (although maybe I missed it?).  But, IMHO, those are _fundamental_ requirements that need to
> be discussed among the WG.  Before touching on any of the other points in Russ White's e-mails
> in this thread, (which I agree with), I think it's important to get back to basics.

what would you add to the reqs draft? (some example/short text to be
fleshed out, bullets?)

> It wasn't discussed with me.  :-)

wanna discuss it now?

-Chris

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 11 Feb 2011 15:39:48 -0500

> session, that can be a pretty big nut to swallow.

if this happens in the normal course of upgrades, over the next 4-7
years... is it still a big deal?

>> ... at least with respect to (b), if I were able to use offboard CPU
>> (i.e.: Intel/AMD servers, like in the RPKI/IRR world), then I have a much
>> larger selection of HW to choose from and I can upgrade those in the network
>> much, much more quickly.
>>
>> At least with respect to #1 and #2, I don't see any discussion of the
>> above in the current draft (although maybe I missed it?).  But, IMHO, those
>> are _fundamental_ requirements that need to be discussed among the WG.
>>  Before touching on any of the other points in Russ White's e-mails in this
>> thread, (which I agree with), I think it's important to get back to basics.
>>
>>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 11 Feb 2011 15:41:13 -0500

> supported on the provider side --possibly with some various government

there have been some provider side folks involved actually... which is
one of the reasons for some of the requirements and assumptions.

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 11 Feb 2011 15:44:05 -0500

> That isn't usually done in real time. It is almost always done on COTS hardware (not on the router it's self).

agreed, there's some cycle to update filters... the problem is that
the source of the filter data is ... horrendous. there's no way to
validate what you THINK should be there vs what IS there. there is no
way to mechanically keep this data updated, to disqualify bad data and
to use quality data.

Auto-adding routes because your customer announces you a route is ...
not a good plan. auto-adding these to the IRR which is then globally
available and not-fixable by the actual origin is also 'bad'.

we can do better, rpki provides a path to making that better. rpki is
not all of the sidr work though.

---

From: Jared Mauch <[email-masked]>
Date: Fri, 11 Feb 2011 16:02:29 -0500

> 2)  Related to point #1, we really should go back to first principles ask ourselves if we're really intending to conflate the _transport_ method (BGP) with the requirement to verify the data _insid…

Because it's the easiest place to do it.  i once had someone tell me that something should be carried in BGP because it was "easier" than duplicating all the code for a new network protocol to do the data copying/replication.  As a non-professional implementer, I considered their opinion valuable.

> ... at least with respect to (b), if I were able to use offboard CPU (i.e.: Intel/AMD servers, like in the RPKI/IRR world), then I have a much larger selection of HW to choose from and I can upgrad…

I think there's a few things here that are certainly valid concerns.  I'd like to refresh them into the following based on my observations:

1) The transport core of the network where all these control-plane messages currently happen is growing and requires dense-high bandwidth routers
2) when you upgrade the router/fabric/whatnot you typically need some new routing-engine, rsp, cpu, etc. that is typically "faster".  Maybe not fast enough for some, but they tend to be "faster".
3) As a percentage cost of an overall upgrade (take t640 -> t1600) the RE component is not the most expensive part by far
4) Cisco/Juniper have some products that are certainly long in the tooth and honestly are too underpowered for even their own aggressive cpu consumption/growth.  It's so bad in cases they don't realize the performance is poor on the older hardware as the labs typically have (on average) newer hardware than in the core provider networks.

As of today, crypto can be expensive if you don't have something designed to accelerate it (eg: hardware assist for SSL on some platforms).  Just because it can be, doesn't mean it is catastrophic.  I'd rather cisco stop leaking memory when processing bgp attributes, but 6 months of the TAC staring at the problem didn't seem to help them. (Or juniper to stop dying due to ipv6 bgp attributes on 4-byte routes).

I don't necessarily trust anyone in this arena.  There's a lot of potential for harm.  I don't want my routers to require on some external device.  You may be willing to live with that, but I can not.  I can not allow my network to be constrained by some COTS PC where the vendors are unwilling to support it, or decide that it's cheaper to just refund the entire cost than fix/replace it (As is happening with HP/Dell on some devices now - google 'sandy bridge' and/or 'cougar point').  While an ECO is something painful for anyone, I would rather it be on something where the vendor is going to stand behind it, vs people who can't trust you to plug in anything (optics, another vendors bgp speaking device, etc) and have their devices operate properly.

There needs to be some built-in inherent trust, and as an operator here's the things i look at/for:

- Ability to simulate something, eg: sidr/roa checks, as_path validation, etc in the cli 
- ability to soft-fail items (appropriate logging/data import and export)
- ability to bootstrap devices
- ability to hard-fail items (above)
- ability to properly log anything!
  (developers are really bad about this, either they dump a full raw hex item, or a worthless message that describes an error condition that is not decipherable as they don't realize they are part of a full system vs their individual zone of importance/ego)

> It wasn't discussed with me.  :-)

I like the fact that Randy has talked about if you do the validation, how much incremental cpu time it takes vs processing a prefix-list/as-paths, etc.  True comparision/data.  I'm sure he can provide you links showing that the "puny" cpus can keep up, and you don't need a 52-way cpu system to process the bgp messages.

(i am also frustrated that too few of my colleagues/peers have time to participate in this stuff, and also that it takes so much time away from my family.. then again, i'm sure i'm some sort of a tech addict as well).

- Jared

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Feb 2011 03:19:08 -0800

>> Route filters in many ISPs are created and validated nightly and
>> pushed to routers if a filter change is needed. 
>> That isn't usually done in real time. It is almost always done on
>> COTS hardware (not on the router it's self). 
> 

actually, at the request of a rather large provider, the rpki data are
faked into a pseudo-irr instance which those who base filters on irr
(for example, the verio/ntt) can use.  e.g.

    rair.local:/Users/randy> whois -h whois.rpki.net 198.180.152.0/24
    route:      198.180.152.0/24
    descr:      198.180.152.0/24-24
    origin:     AS4128
    notify:     [email-masked]
    mnt-by:     MAINT-RPKI
    changed:    [email-masked] 20100914
    source:     RPKI

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Feb 2011 03:34:43 -0800

> I think there's a few things here that are certainly valid concerns.
> I'd like to refresh them into the following based on my observations: 
> 
> 1) The transport core of the network where all these control-plane
> messages currently happen is growing and requires dense-high bandwidth
> routers 
> 2) when you upgrade the router/fabric/whatnot you typically need some
> new routing-engine, rsp, cpu, etc. that is typically "faster".  Maybe
> not fast enough for some, but they tend to be "faster". 
> 3) As a percentage cost of an overall upgrade (take t640 -> t1600) the
> RE component is not the most expensive part by far 
> 4) Cisco/Juniper have some products that are certainly long in the
> tooth and honestly are too underpowered for even their own aggressive
> cpu consumption/growth.  It's so bad in cases they don't realize the
> performance is poor on the older hardware as the labs typically have
> (on average) newer hardware than in the core provider networks. 
> 
> As of today, crypto can be expensive if you don't have something
> destheigned to accelerate it (eg: hardware assist for SSL on some
> platforms).

crypto assist is getting pretty cheap and will continue to get cheaper.

as a vendor friend said, we're gonna be upgrading in the 3-5 year
time-frame anyway to get routers that can forward ipv6 at the same rate
as ipv4. :(

we have been talking in circles about securing inter-domain routing for
over a decade.  if we lay out a plan and start actually moving forward,
our 'natural' core hardware upgrade cycle is on the order of half that
time.

or we can explain to the wsj why we still have no plan when the next
youtube accident occurs.

randy

---

From: Yann Berthier <[email-masked]>
Date: Sat, 12 Feb 2011 09:29:36 -0500

>    rair.local:/Users/randy> whois -h whois.rpki.net 198.180.152.0/24

Cool !

Are you mirroring the rirs and others' rpkis ?

I suppose the code to slurp them and shoehorn the result into a local irrd is avail, so we could deploy that alongside our internal irrd ?

- y

---

From: Christopher Morrow <[email-masked]>
Date: Sat, 12 Feb 2011 10:39:05 -0500

>    descr:      198.180.152.0/24-24

oh lookie, someone did the join for me :)

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Feb 2011 09:27:00 -0800

> Are you mirroring the rirs and others' rpkis ?

it is from a rcynic rpki cache, i.e. the transitive cone under the best
trust anchors we can glean today

> I suppose the code to slurp them and shoehorn the result into a local
> irrd is avail, so we could deploy that alongside our internal irrd ?

you are looking at an irrd instance, so yes, of course

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Feb 2011 09:44:21 -0800

> you are looking at an irrd instance, so yes, of course

btw, way back when, kurtis and i asked ripe and apnic for this.  we got
told to submit policy proposals.  we did.  they sat for a year+.  one
day i asked rob austein for it.  we had it late the same day.  

within a month, ripe had invented it.  it seems that the way to get rirs
to do things is to give them something to [re-]invent and plant their
flag on it.  whatever.

randy

---

From: Yann Berthier <[email-masked]>
Date: Sat, 12 Feb 2011 20:24:44 -0500

> you are looking at an irrd instance, so yes, of course

just in time for valentine's day

is there any doco to get started, or is this a matter of running something like rcynic + http://subvert-rpki.hactrn.net/scripts/roa-to-irr.py ?

---

From: Randy Bush <[email-masked]>
Date: Sat, 12 Feb 2011 17:34:06 -0800

> is there any doco to get started, or is this a matter of running
> something like rcynic +
> http://subvert-rpki.hactrn.net/scripts/roa-to-irr.py ?

you've got the recipe for building your own from open source

randy

---

From: Russ White <[email-masked]>
Date: Sun, 13 Feb 2011 07:21:42 -0500

> one of the reasons for some of the requirements and assumptions.

I had always thought the idea of the IETF process was to bring the
assumptions out to the light of day, not to build them into the drafts
(?)... IE, put the assumptions on the table. There are some actual
requirements coming out of this thread --why not record them in the
document, so they can be discussed in the open, rather than "assuming" them?

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Sun, 13 Feb 2011 07:33:43 -0500

> Because it's the easiest place to do it.  i once had someone tell me that something should be carried in BGP because it was "easier" than duplicating all the code for a new network protocol to do t…

I don't agree... It might be easy enough to use the same transport, but
to carry in the same session --eventually you get to the point where you
have everything being carried across one protocol. Is it working well to
carry real time and streaming voice, real time and streaming video, ftp
type data files, text, and a ton of other stuff in HTTP? How do you
build QoS around this? Deep packet inspection?

TRILL used IS-IS, but put it in a different process. There's a lot to be
said for reusing code and ideas, and a lot to be said for splitting up
failure domains, databases, and transport instances.

> 4) Cisco/Juniper have some products that are certainly long in the tooth and honestly are too underpowered for even their own aggressive cpu consumption/growth.  It's so bad in cases they don't rea…

"Underpowered" is a matter of opinion. A netbook is "underpowered" for
some things, and perfectly powered for others. So is an iPad, and I
don't see  lot of people carrying around 6TB is drive space and 8GB of
main memory with a quad core processor in their pockets --and yet people
don't seem to complain about underpowered smart phones.

If you're going to change a router into a fast compute platform with a
lot of disk and processing requirements, it's going to take a while to
make the proper adjustments.

> I don't necessarily trust anyone in this arena.  There's a lot of potential for harm.  I don't want my routers to require on some external device.  You may be willing to live with that, but I can n…

But you're making the assumption that whatever security device exists
must be "plugged in" to the router physically. This is a bad assumption,
IMHO. There is a market for firewall code in routers. There is a market
for firewalls that are independent of routers.

Again, this is part of the problem with the document --assumptions like
this are buried under the covers. Bring them into the light of day, so
we can discuss them.

> I like the fact that Randy has talked about if you do the validation, how much incremental cpu time it takes vs processing a prefix-list/as-paths, etc.  True comparision/data.  I'm sure he can prov…

But Randy has already said that those parts of the draft have nothing to
do with performance, but security only...

> (i am also frustrated that too few of my colleagues/peers have time to participate in this stuff, and also that it takes so much time away from my family.. then again, i'm sure i'm some sort of a t…

OTOH, this is going to have a major impact on your operations in the
next few years. You need to think carefully about:

1. What is it you're trying to accomplish --what problem are you trying
to solve?
2. Where do you want this complexity?
3. Do you want to assume BGP is where it should be for the next 20
years, or do you think we need to put security within a plan for pushing
BGP along to something newer and better?

One of my underlying assumptions is there won't ever be a "flag day,"
for BGP, so whatever we do for security now, we must either work around
to push BGP forward, or we must live with permanently.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Sun, 13 Feb 2011 07:49:15 -0500

> proper and pass it on. you have no real way to tell if the route was

Isn't this what NO_EXPORT is for? Is the entire point of this exercise
to encrypt one community?

> the as-path aside from what the text says. (see pilosov/kopella)

What sort of policy do you want to infer from the as path beyond the
first hop? This is what needs to be in the requirements draft.

Come'on, you're a provider! Don't think about what you want the protocol
to look like, think about what you want the protocol to accomplish! You
stated one thing above, but that really needs some clarity around it
--what policies do you think you can infer from the AS Path?

For instance, given this:

A---------B
|         |
+---C-----+

Is the point for B to be able to control whether or not A accepts routes
from C? In other words, is the point to control A's policy towards C, or
to inform A of your policy towards C? Can you actually inform A of your
policy towards C without telling A what your policy towards C is?

:-)

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 13 Feb 2011 13:01:27 -0500

> to encrypt one community?

huh? no, the first (right-most) asn in the path, is that who actually
originated the route? Are they permitted to originate that route by
the netblock 'owner'?

these are the questions, I think, origin validation should solve.

> first hop? This is what needs to be in the requirements draft.

I thought it was ... req 3.12 covers what you'd want to do with the
as-path security information. (or really says you can influence the
addition to the RIB of a route based on it's security
information/state)

> to look like, think about what you want the protocol to accomplish! You

sure, 'tell me if the path I see is a lie' (in rough terms)... in more
complex terms: "verify, with a high degree of certainty, that each hop
on the supposed path actually saw this copy of this route. Verify,
with a high degree of certainty, that the origin of this route is
authorized to make this announcement."

Ideally, with that information I should be able to better inform my
route selection process.

> --what policies do you think you can infer from the AS Path?

if something like:
<http://www.renesys.com/tech/presentations/pdf/blackhat-09.pdf>

happens, do not accept the affected routes. Sure, if the provider(s)
to the customer doing this all did prefix and as-path filtering we
wouldn't require much else... except that almost no 'Tier-1' to
'tier-1' isp peerings are filtered in a meaningful way.

> from C? In other words, is the point to control A's policy towards C, or

nope.

> policy towards C without telling A what your policy towards C is?

nope.

The point is to see if along the path a-b-c if the routes C originates
C is supposed to be able to originate (rpki helps here), and if B has
changed the basica data about the prefixes C sent it, and to make sure
that we don't suddenly start accepting routes with paths like:

a-b-d-c
a-b-d-e-f-c

since d, e, f can't sign the paths... unless of course they suddenly
do appear in the path and are properly signing things.

I don't think it's helpful to tell people what your policy is, nor to
control external entities by hoping to infer their policy. I do think
there is some sense in knowing that the route I see is originated by
an authorized party and that no unauthorized parties are showing up in
the paths I see.

I may chose to do nothing with the information as I receive it, or I
may chose to prefer 'valid' routes over 'invalid' (or even 'unknown')
routes... that's purely a local operator decision.

-Chris

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 13 Feb 2011 13:03:05 -0500

On Sun, Feb 13, 2011 at 1:01 PM, Christopher Morrow
<[email-masked]> wrote:

referencing all of the messages I've sent on this topic
(bgpsec-reqs-00 draft discussions) ... all said purely as a reader of
the draft and participant in the sidr wg...

<co-chair-snuggie == off>

thnx!

---

From: Russ White <[email-masked]>
Date: Sun, 13 Feb 2011 14:13:43 -0500

> these are the questions, I think, origin validation should solve.

Okay, first, this document isn't about origin validation, it's about
path validation. So, when you say, "you believe it's proper and you pass
it on," in the context of this document, specifically, you can't be
talking about the origin, but only the _other_ AS numbers listed in the
AS Path.

> addition to the RIB of a route based on it's security

No, it just says you can use this information to influence what you put
in your local RIB. That doesn't tell me what question you're trying to
answer. It only says, "my requirement is that the path be signed, and
that I can decide what I want to with that signature."

It's like your customer comes to you and says, "I want you to build me a
10,000 node L2VPN." You could just say, "sure, it'll cost you x." But if
you're intelligent, you'll have a design person on staff who works will
sales who understands, from the outset, that this is a disaster going
someplace to happen --so you ask, "what is the problem you're trying to
solve?" If the customer comes back with, "I'm trying to build a 10,000
switch layer 2 network," have they answered your question?

> on the supposed path actually saw this copy of this route. 

Why do you care if they're lying? Explain what the problem is if they
are. Don't say, "I don't want you to lie to me." Say, "when someone lies
to me, this is what happens, and I need to be able to prevent that from
happening."

>> +---C-----+

Even though you say you don't. Whether a peering relationship is tier 1
to 2, or the other way around, _is_ a policy --because the specific
question here is --should C be transiting traffic to A?

In other words, you're contradicting yourself --you're saying, "I don't
want to infer or enforce policy," but then you go on to say, "this
specific violation of policy is what I'm trying to prevent from happening."

> that we don't suddenly start accepting routes with paths like:

In other words, you want to be certain that it's within C's policy to
advertise the route to D, and it's not within C's policy to advertise
the route to F.

> an authorized party and that no unauthorized parties are showing up in

But that's precisely what you're trying to do...

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Sun, 13 Feb 2011 14:19:57 -0500

> question here is --should C be transiting traffic to A?

Bah --between A and B.

:-)

Russ

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 13 Feb 2011 20:55:30 -0500

> Okay, first, this document isn't about origin validation, it's about

yes, coffee failure.

> talking about the origin, but only the _other_ AS numbers listed in the

sure, they signed it, the previous as's signed their copy as it passed
through. if there's an unsigned as in the path, or a miss-signed
one... the path fails validity checks and I can decide something from
that.

> that I can decide what I want to with that signature."

yes.

> to me, this is what happens, and I need to be able to prevent that from

that's said below. 'do not accept the affected routes'
You want: "Because sending traffic off on a false path causes
pain/suffering/unhappy-packets"
added to the reqs doc?

> Then you want to know what the policy is in this diagram:

perhaps 'policy' is overloaded here... I don't care what the bgp
policy is inside someone else's network. they can choose to
accept/deny/up|down-pref announcements to their hearts content. I do
care that, as I said below/before, someone can't invent paths in the
routing table.

> to 2, or the other way around, _is_ a policy --because the specific

I knew using the moniker 'tier-1' was going to bite me... "large
settlement-free peers".

> question here is --should C be transiting traffic to A?

actually even in the case of your 3 ASN picture, I don't think we can
meaningfully limit route leaks with JUST protocol fixes. We could,
however, use the rpki infrastructure to put in proper prefix-filters
on the peers in question.

>> changed the basic data about the prefixes C sent it, and to make sure

nope.
I want to (for the 2 example paths above, applied to the diagram you
created) be certain that in case 1:
B is not injecting routes with origin-C and as-path that includes
fictional-ASN-D

case 2:
B is not injecting a path with origin-C and as-path that includes the
fictional ASNs D, E, F

I didn't speculate on the policy of B nor C here, just that the path I
see isn't signed by asn's D E nor F, so they shouldn't be used in this
network.

nope.

-chris

---

From: Shane Amante <[email-masked]>
Date: Mon, 14 Feb 2011 10:07:20 -0700

Chris,

Rather than waste a lot of time doing a point-by-point response, let's boil this down to the most simple question.  Once we get a common understanding on that, we can (hopefully) discuss other points.

First, I understand how the current RPKI is intended to be deployed and operationalized.  I also acknowledge the present "capabilities" in the RPKI that we knew about the time RPSEC wound down and SIDR was formed, namely that the RPKI only contains ROA's, and associated certificate material, that is intended to allow 3rd-parties to authenticate a given ASN is "allowed" to originate a given prefix (or, set of prefixes, i.e.: /16 upto /24).  However, and here's the key part, in my understanding all RPKI material (namely, ROA's and associated certificate material) is carried around "out-of-band" amongst a hierarchy of 'commodity' servers from IANA -> RIR's -> LIR's/ISP's.  At present, there's two things SP's may do to get that material from those servers into their routers, (doing the actual forwarding):
1)  "Pull Model": Routers can use draft-ietf-sidr-rpki-rtr-07 to pull RPKI info from the RPKI servers and absorb it into their configuration; or,
2)  "Push Model": Operators can (re-)use their existing tool-chains, if they so desire, to push information from the RPKI servers into their routers using existing BGP policy-statements/route-maps applied to eBGP sessions that have existed for several years.

Either of those models will work.  However, and again here's the key point, either of the above are *not* forcing any RPKI information, (in particular ROA's, certs, CRL's, etc.), in BGP transport sessions.  IOW, BGP continues to blindly (and, quickly) pass around forwarding information and it's up to [very simple] policy on each router to decide whether to accept or reject that forwarding information as "legitimate".  OTOH, if my understanding of this draft is correct, we're talking about moving away from that and carrying not just forwarding information, but also certs and possibly other RPKI material, etc.?  Why?  Or, more importantly, why is that a MUST?  Why can't additional RPKI material, (e.g.: beyond ROA's), continue to be pulled or pushed into routers as I outlined above, (in particular Model #2)?

-shane

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 14 Feb 2011 12:22:33 -0500

> Rather than waste a lot of time doing a point-by-point response, let's boil this down to the most simple question.  Once we get a common understanding on that, we can (hopefully) discuss other poin…

sounds great.

> 1)  "Pull Model": Routers can use draft-ietf-sidr-rpki-rtr-07 to pull RPKI info from the RPKI servers and absorb it into their configuration; or,

I think not 'configuration' but 'on router cache' - akin to a dns-cache...

> 2)  "Push Model": Operators can (re-)use their existing tool-chains, if they so desire, to push information from the RPKI servers into their routers using existing BGP policy-statements/route-maps…

yup, 'make me a prefix-list'

> Either of those models will work.  However, and again here's the key point, either of the above are *not* forcing any RPKI information, (in particular ROA's, certs, CRL's, etc.), in BGP transport sessions.  IOW, BGP continues to blindly (and, quickly) pass
around forwarding information and it's up to [very simple] policy on
each router to decide whether to accept or reject that forwarding
information as "legitimate".  OTOH, if my understanding of this draft
is correct, we're talking about moving away from that and carrying not
just forwarding information, but also certs and possibly other RPKI
material, etc.?  Why?  Or, more importantly, why is that a MUST?  Why
can't additional RPKI material, (e.g.: beyond ROA's), continue to be
pulled or pushed into routers as I outlined above, (in particular
Model #2)?

roa's don't end up in bgp even in the case of this draft, nor do
certs. 'signed updates' do. An optional-transitive attribute is one
model to look at using for this, I think. I think the reasoning behind
carrying a signature (well, adding a signature at each AS-hop) is so
you can see that the AS in the path has actually seen this
announcement.

The presence of the signature data and your router checking that ends
with (as the draft says) "valid" or "invalid", you can choose to do
something with that in your local bgp policy, for example:

route-map bloop permit 10
  match validity-state valid
  set localpref 100
route-map bloop permit 20
  match validity-state invalid
  set localpref 5

I don't want to see certs or roas shipped in bgp either, shipment of
that data remains in the rpki 'system'.

-Chris

---

From: Shane Amante <[email-masked]>
Date: Mon, 14 Feb 2011 10:26:34 -0700

Jared,

See below.

On Feb 11, 2011, at 14:02 MST, Jared Mauch wrote:
[--snip--]
> I don't necessarily trust anyone in this arena.  There's a lot of potential for harm.  I don't want my routers to require on some external device.  You may be willing to live with that, but I can not.

In fact, I would say my network is the complete opposite.  :-)  I already depend on external COTS servers for a variety of mission critical functions in the network: IRR, DNS, Netflow collection/processing, SNMP stats, syslog messages, syslog processing, etc.  (I would be shocked if other networks don't have similar requirements for external COTS servers).

> I can not allow my network to be constrained by some COTS PC where the vendors are unwilling to support it, or decide that it's cheaper to just refund the entire cost than fix/replace it (As is happening with HP/Dell on some devices now - google 'sandy bridge' and/or 'cougar point').  While an ECO is something painful for anyone, I would rather it be on something where the vendor is going to stand behind it, vs people who can't trust you to plug in anything (optics, another vendors bgp speaking device, etc) and have their devices operate properly.

(Sorry the following strays a bit off-topic for a technical mailing list, but I wanted to inject the operational reality as I see it from my vantage point).

Ultimately, I understand "different strokes for different folks".  My main point is: SIDR can't (or, at the very least) should not force a single operational or deployment model (i.e.: in-band transport in BGP of certs, etc.) on operators.  To emphasize this point further:
- Different networks have different EOL replacement strategies and, more importantly, timelines.  
- While some networks may be limited to only sourcing network equipment from a limited set of vendors, others are not.  Requiring crypto-assist onboard routers is likely to either take a very long time for a broader set of vendors to implement or have them abandon the market altogether.  Both would be very bad outcomes IMHO.

Thanks,

-shane

---

From: Sandra Murphy <[email-masked]>
Date: Mon, 14 Feb 2011 12:32:33 -0500 (Eastern Standard Time)

> Either of those models will work.  However, and again here's the key point, either of the above are *not* forcing any RPKI information, (in particular ROA's, certs, CRL's, etc.), in BGP transport s…

I don't believe that any requirement in this draft forces carrying certs 
or other RPKI data around in BGP.  The current deployment out-of-band will 
continue to work.

Please point to specific language in the requirements document that 
dictates changing the current sidr model.

--Sandy

---

From: Russ White <[email-masked]>
Date: Mon, 14 Feb 2011 17:20:55 -0500

> pain/suffering/unhappy-packets"

No, I want to know what it is you intend to accomplish, not how you
intend to accomplish it.

> care that, as I said below/before, someone can't invent paths in the

Policy exists outside an AS, as well. When you set no_export on a route,
that's a policy. When you sign a contract saying, "I will peer with you,
but I will not allow you to transit my traffic," that's a policy. If
you'd like to suggest a different word for contract terms that say
things like, "I will peer, but not transit," then lets find the better term.

Let's go back to here:

A---------B
|         |
+---C-----+

> B is not injecting routes with origin-C and as-path that includes

The requirement here is that you don't want fictional AS' in the AS Path.

> see isn't signed by asn's D E nor F, so they shouldn't be used in this

The second point you make is that you don't care if C transits or not in
this situation. If you're B, you don't care if C is supposed to transit
or not, so long as C doesn't put a fake AS in the AS Path.

So the only real requirement you have is that fake AS' not end up in the
AS Path. Is that correct?

:-)

Russ

---

From: Dongting Yu <[email-masked]>
Date: Tue, 15 Feb 2011 01:25:03 +0000

A few questions and comments. I don't think they have been mentioned
before, excuse me if they have.

   3.1   A BGPsec design MUST be able to be incrementally deployed on
         today's Internet.

Does this allow for long-term eventual coexistence of BGPsec and
normal BGP without compromise of security of the BGPsec? I can imagine
scenarios where incremental deployments are possible at the cost of a
weaker assurance, but with the expectation that eventually at least
islands will appear where BGPsec is used everywhere (and only then
will BGPsec be in full power).

   3.3   As cryptographic payloads and loading on routers are likely to
         seriously increase, a BGPsec design may require use of new
         hardware.  It must be possible to build routers that do BGPsec
         with within acceptable (to operators) bounds of cost and
         performance.

may -> MAY, must -> MUST?

Are we talking about absolute assurance or probabilistic (with a
tunable confidence value) assurance? Is a distinction needed?

   4.3  Replay of BGP UPDATE messages need not be completely prevented,
        but a BGPsec design MUST provide a mechanism to control the
        window of exposure to replay attacks.

Is this control mechanism something that each AS can choose?

Dongting

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Feb 2011 10:50:53 +0800

> will BGPsec be in full power).

yes.  though i imagine the security assertions you can make between two
BGPsec islands across a non-secured gap could be weak.  interesting
issue.

> may -> MAY, must -> MUST?

what i have in my edit buffer is

   3.3   As cryptographic payloads and memory requirements on routers
         are likely to increase, a BGPsec design MAY require use of new
         hardware.  I.e. compatibility with current hardware abilities
         is not a requirement that this document imposes on a solution.
         As BGPsec will likely not be rolled out for some years, this
         should not be a major problem.

> Are we talking about absolute assurance or probabilistic

the intent is absolute, as much as there are absolutes in this life

> Is this control mechanism something that each AS can choose?

i believe that the intent is that the originator of the prefix would be
able to choose.

randy