Subject: [sidr] draft-sriram-bgpsec-design-choices-00 -- IXP and Route Server

From: "Chris Hall" <[email-masked]>
Date: Fri, 8 Jul 2011 10:50:59 +0100

I am working on Quagga, on behalf of Euro-IX, to allow for future
growth and other developments specific to the needs of a Route Server.

The discussion in 7.4.2 is incomplete.  It may be true that traffic is
80:20 in favour of direct bilateral peering (Method A).  However, that
does not mean that 80% of the peering connections are bilateral
peering -- the distribution of traffic amongst peering connections has
the usual long tail.  Numbers vary, but a large exchange may have 50%
of its clients connected to the route server for most (if not all) of
their peering connections.

Section 6.6 discusses Proxy Signing.  Where a route server is not
inserting its own AS in the path (Method B), it is acting as a proxy
for each route server client.  Given a certificate and private key
from each client, the route server can rewrite the most recent
signature.  So, and please correct me if I have this wrong, the case
is covered ?

Incidentally, the discussion notes that router servers that insert
their AS in the path (Method C) are rare.  I'd put it more strongly
than that, and relegate the case to "footnote" status.  With such a
route server the IXP has all the appearance of a transit provider (at
least at the route level), so would be trivially supported -- at least
until some mechanism is devised to validate the AS Path and the path
taken by packets against each other.  

Chris

---

From: Randy Bush <[email-masked]>
Date: Fri, 08 Jul 2011 19:51:39 +0900

i have a design that covers you.  it is based on an 'optimization' and
we have agreed to let optimizations sit for a bit.

the hack is as follows <hold nose>:

  o an early optimization will be that each bgpspeaking AS adds a one
    byte prepend count, over which it signs.  this saves signing 92
    prepends.  the count is normally one.

  o a bgpsec-speaking 'transparent' route server signs over a zero
    prepend count.

  o bgpsec speakers calculate as path length by summing prepend counts.

  o a bgpsec speaker passing a signed announcement to a non-speaker
    expands all prepends.  of course, the expansion of a zero prepend
    is rather small.

<release nose>

randy

---

From: "Chris Hall" <[email-masked]>
Date: Fri, 8 Jul 2011 14:37:29 +0100

Randy Bush wrote (on Fri 08-Jul-2011 at 11:52 +0100):
> i have a design that covers you.  it is based on an 'optimization'
> and we have agreed to let optimizations sit for a bit.

OK.  But I quibble with the notion that support for Route Servers
should be treated as an "optimisation".

>   o an early optimization will be that each bgpspeaking AS adds
>     a one byte prepend count, over which it signs.  this saves
>     signing 92 prepends.  the count is normally one.

OK.  That clears up a confusion I had... I wasn't sure whether there
was supposed to be one signature per ASN in the path, or one per
*distinct* ASN in the path.  For my money, prepending is common enough
to merit covering as a "feature.

>   o a bgpsec-speaking 'transparent' route server signs over a zero

You're right: <HOLD NOSE> indeed.
 
That would be, as you suggest, less 'transparent' than it used to be.
I don't know if "revealing" the use of the route server is a serious
issue.  But I'm not sure how much is gained by inserting the route
server ASN ?

It seems reasonable to me to treat the route server as an extension of
its clients' networks -- that's pretty much what it is.  So, if the
route server uses a different key for each client's routes, and the
*client* is responsible for issuing the certificate (as if the route
server were one of its routers), then that about covers it -- unless I
am missing something ?

I suppose that if the route server went off the reservation it could
sign all kinds of rubbish as being announced by its clients, but the
owners of the certificates could revoke them ?

BTW (and sorry if this is a stupid question) where should I be looking
for a discussion of the key/certificate management for AS Path signing
keys ?  This is intended to be added into the RPKI, yes ?

>   o bgpsec speakers calculate as path length by summing prepend

Are you suggesting placing the prepend count in the AS Path itself ?
Say, an AS_SEQUENCE_N, which is like an AS_SEQUENCE, but has a 1 byte
repeat count for the first ASN in the sequence ?  That would pay for
itself (bytes-wise) and mean that where there is no prepending, there
is no overhead -- except for the inclusion of the count (implied or
explicit) in the signed data.

>     expands all prepends.  of course, the expansion of a zero
>     prepend is rather small.
> 
> <release nose>

<collapse of stout party>

Chris

---

From: Randy Bush <[email-masked]>
Date: Fri, 08 Jul 2011 22:50:44 +0900

> should be treated as an "optimisation".

it is compressing prepends that is the optimization.  transparent route
servers are not an optimization, they're a hack.

> to merit covering as a "feature.

prepending is supported in the current spec.  the problem is that there
is one signature per prepend, expensive.

> issue.  But I'm not sure how much is gained by inserting the route

maintaining bgpsec.  if A hands announcement to RS and RS hands to B and
C truely transparently, to whom does A forward sign the announcement, B
or C?  #faceplant

> server were one of its routers), then that about covers it -- unless I

so, A has to know all the ASs to which RS will hand route, forward sign
announcements to each of them and hand all those to RS, and RS then
stores them all and forwards as appropriate.  that'll scale really well.

omg!  on reread it seems you are giving A's private key to RS.  not a
fracking chance in hell.  you just blew the trust model to hell.

> Are you suggesting placing the prepend count in the AS Path itself ?

see slide 29 of https://archive.psg.com/110614.nanog-bgpsec.pdf

randy

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 08 Jul 2011 16:04:50 +0200

> stores them all and forwards as appropriate.  that'll scale really well.

IX are used for optimizing local traffic patterns. Only very few 
applications of IX are about Internet peering broker service (but let's 
keep those out for the time being).

So if we assume that A wants to give some of his addresses to B & C via 
RS why do they need to bother with bgpsec at all ?

When A advertises it's nets to it's Internet providers yes it will 
forward sign it properly so they will be announced everywhere according 
to BGPsec rules.

Imagine an IX without RS ... A wants to peer with B and both establish a 
peering relation I really see no need why they should get any of 
additional security on top of their direct route exchange as B will not 
be a transit for A anyway.

Rgs,
R.

---

From: "Chris Hall" <[email-masked]>
Date: Fri, 8 Jul 2011 15:57:36 +0100

Randy Bush wrote (on 08-Jul-2011 at 14:51 +0100):
> Chris Hall wrote:
> > ... But I'm not sure how much is gained by inserting the
> >     route server ASN ?

> maintaining bgpsec.  if A hands announcement to RS and RS hands to B
> and C truely transparently, to whom does A forward sign the
> announcement, B or C?  #faceplant

A signs it's announcements to RS in the usual way, with the RS ASN as
the next AS hop.

When announcing A's routes to B, the RS *rewrites* the signature it
received, using the key it has for A, as if A had announced the route
directly to B.  Clearly the RS would be required to preserve the
Expire Time on any routes originated by A.  Similarly, announcing A's
routes to any other AS.

Unless that is somehow impossible...

....
> omg!  on reread it seems you are giving A's private key to RS.  not
> a fracking chance in hell.  you just blew the trust model to hell.

...yes, I'm suggesting that A delegates a unique signing key to the
RS.  It is still A's key, so in terms of the trust model, it is
covered by A's CA.  This is what "6.6 Proxy Signing" in
draft-sriram-bgpsec-design-choices suggests, is it not ?  Or does that
blow the trust model to hell, also ?

Chris

---

From: Randy Bush <[email-masked]>
Date: Sat, 09 Jul 2011 03:23:32 +0900

> I'm suggesting that A delegates a unique signing key to the RS.

the expression we use is, now RS can sign gifs of naked furries in A's
name.  i.e. A has given away the store.  you do NOT let anyone else have
your private keys.

for example. in this context, RS can now give that key to Perp who can
originate A's prefixes.  #fail

> This is what "6.6 Proxy Signing" in

it does indeed.  that is why 6.6 was rejected.

randy

---

From: "Chris Hall" <[email-masked]>
Date: Fri, 8 Jul 2011 19:55:31 +0100

Randy Bush wrote (on Fri 08-Jul-2011 at 19:24 +0100):
....
> > draft-sriram-bgpsec-design-choices suggests, is it
> > not ?  Or does that blow the trust model to hell,
> > also ?

> it does indeed.  that is why 6.6 was rejected.

Ah.  There I was, reading a draft of 5-Jul-2011 and thinking I was up
to date :-(

OK.  If the RS ASN is in the path, then nobody needs to depend on the
integrity of the RS (however trustworthy one may expect them to be).
I look forward to the ASN count mechanism appearing in the draft(s),
and support for Route Servers making its way into the Requirements.

Chris

---

From: Randy Bush <[email-masked]>
Date: Sat, 09 Jul 2011 04:02:20 +0900

> keep those out for the time being).

ixen are used for all sorts of things, including transit.

> RS why do they need to bother with bgpsec at all ?

because A, B, and C have bgpsec speaking customers who want their
prefixes protected.

> forward sign it properly so they will be announced everywhere according 

it's not just A's prefixes, it's also A's customers' prefixes.

> Imagine an IX without RS ... A wants to peer with B and both establish
> a peering relation I really see no need why they should get any of
> additional security on top of their direct route exchange as B will
> not be a transit for A anyway.

first, you have no idea whether they are transit or not.  the business
models across exchanges are quite diverse.

second, both A and B have CUSTOMERS.  A and B received those prefixes as
signed, and A's and B's receiving customers want to receive them via
bgpsec.

no one's customers want to have their security reduced just because an
upstream or more complex business partner uses an exchange point.
weakened security does not sell well.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 09 Jul 2011 04:06:42 +0900

>>> draft-sriram-bgpsec-design-choices suggests, is it not ?  Or does
>>> that blow the trust model to hell, also ?

sriram's document represents the design team's thought processes, and
therefore includes things which were rejected in the design.

the bgpsec protocol documents are, i think, still are

    draft-ietf-sidr-bgpsec-overview-00.txt
    draft-ietf-sidr-bgpsec-protocol-00.txt

> integrity of the RS (however trustworthy one may expect them to be).

bingo!

> and support for Route Servers making its way into the Requirements.

i am still selling my hack to the design team.

randy

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 8 Jul 2011 15:30:19 -0400 (Eastern Daylight Time)

> Ah.  There I was, reading a draft of 5-Jul-2011 and thinking I was up

The previous section, 6.5, lists alternatives for handling stub ASs. 
Note that alternative 2 is the same description as 6.6, but alternative 2 
was not the chosen alternative.  That might be what Randy meant when he 
said "rejected."

Section 6.6 rightly notes that if an AS decided to share its private key 
with another AS, no one outside the agreement could tell the difference.

Therein lies the power and the danger of sharing private keys.

--Sandy, regular ol' wg member

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 08 Jul 2011 22:11:22 +0200

On the previous post I just wanted to limit such bgpsec less exchange to 
stub customers only. But I agree and stand corrected that if we solve it 
for all - transit included - then there is no need to make any special 
treatment for stubs. Question withdrawn.

---

However I would like to ask for some clarification on why bgpsec is all 
about securing advertised nets and does not (at least to the best of my 
knowledge) certify that such prefixes have been advertised with 
legitimate next hops (the one which the prefix owner really owns). I 
browsed the respective drafts and did not find a trace of such.

If we talk about RS in particular such RS is not in the data path hence 
it is not modifying next hops as received from his clients.

How are we going to protect the paths from compromised RS where the 
prefixes are advertised correctly but next hops are bogus ? What's worse 
client's customers connected via such RS may have chosen such paths as 
best even if they have alternatives ...

Thx,
R.

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 8 Jul 2011 19:26:38 -0400

Sandy's observations are correct.
Further, the topic of Section 6.6 cannot be either "accepted" or "rejected"
as a matter of BGPSEC protocol specification.
It is merely a statement that _outside_of_the_BGPSEC_protocol_specification_,
any two consenting ASes can have this private arrangement.
Section 6.6 clearly notes thus:   
"This is a private arrangement between said parties and is invisible to other ASes.  
Thus, this arrangement is not part of the BGPSEC protocol specification."
http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-00#section-6.6 

Sriram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Sandra Murphy
> Sent: Friday, July 08, 2011 3:30 PM
> To: Chris Hall
> Cc: 'sidr wg list'
> Subject: Re: [sidr] draft-sriram-bgpsec-design-choices-00 -- IXP and Route Server
> 
> 
>

---

From: "Chris Hall" <[email-masked]>
Date: Sat, 9 Jul 2011 10:37:40 +0100

> Sandy's observations are correct.
...
> "This is a private arrangement between said parties and
>  is invisible to other ASes.  Thus, this arrangement is
>  not part of the BGPSEC protocol specification."

Strictly entre nous, I don't get a strong sense from the text that
entering into such an arrangement is an obvious and foolish mistake
:-}  Unlike, for example, an ISP using its own key to proxy sign for a
customer, which is "considered a bad idea".

Chris

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Sat, 9 Jul 2011 09:30:24 -0400

>customer, which is "considered a bad idea".

If an ISP (or IXP/RS) and its customer feel strongly that they have a long trusted relationship,
and they are comfortable with this type of arrangement (outside of BGPSEC
but still only to allow them to perform BGPSEC more efficiently or with lower cost), 
what good does it do to tell them that they are making "an obvious and foolish mistake"?
They also know that the customer can revoke the EE cert and annul the 
router (or RS)-specific private key if the relationship ends or trust
is compromised (Section 6.6.2).   

Having said that, I respect Randy's viewpoint (and yours -- seems you are in agreement).
There is no conflict here since it is not about BGPSEC protocol specification.
This is about operational best practices.
We can revise Section 6.6 to put greater emphasis on the "cons" part of it.

Sriram
________________________________________

---

From: Randy Bush <[email-masked]>
Date: Sat, 09 Jul 2011 23:56:44 +0900

> legitimate next hops (the one which the prefix owner really owns).

considering next hop likely changes at AS boundaries (and for some ops
practice, within the AS), how and why would one sign it?  e.g. at the
boundary between A and B, why bother having A sign it across what should
be a trustable boundary.

and, if A did sign it, and B changes the next hop when handing the
update on to C, A's signature just got farbled.

so bottom line, imiho, what's the need, and doing it would break things.

randy

---

From: Roque Gagliano <[email-masked]>
Date: Sat, 9 Jul 2011 17:00:49 +0200

Randy,

> originate A's prefixes.  #fail

I do not follow this reasoning. The certificate for BGPSEC are EE certificates with only A's ASN in its RFC3779 extension. So, you cannot use the same key to sign a ROA with another ASN nor issue any certificate using that same key.

IMHO, A good idea could be to clearly identify BGPSEC EE certs in the RPKI repository by assign them a distinct Extended Key Usage (EKU). The use of EKU is permitted by the RPKI CP. The EKU should be checked by the RP during the validation process.

Roque

---

From: Sandra Murphy <[email-masked]>
Date: Sat, 9 Jul 2011 19:05:26 -0400 (Eastern Daylight Time)

On Fri, 8 Jul 2011, Robert Raszuk wrote:

>
> On the previous post I just wanted to limit such bgpsec less exchange to stub 
> customers only. But I agree and stand corrected that if we solve it for all - 
> transit included - then there is no need to make any special treatment for 
> stubs. Question withdrawn.
>
> ---
>
> However I would like to ask for some clarification on why bgpsec is all about 
> securing advertised nets and does not (at least to the best of my knowledge) 
> certify that such prefixes have been advertised with legitimate next hops 
> (the one which the prefix owner really owns). I browsed the respective drafts
> and did not find a trace of such.

The owner of the advertised prefix doesn't have ownership of the next hops 
along the path. nor does it have anything to say about the legitimacy of 
next hops along the path.

There's this whole "third part next hop" concept which would make 
determining legitimacy of the next hop complicated.

--Sandy, speaking as regular ol' wg member

>
> If we talk about RS in particular such RS is not in the data path hence it is 
> not modifying next hops as received from his clients.
>
> How are we going to protect the paths from compromised RS where the prefixes 
> are advertised correctly but next hops are bogus ? What's worse client's 
> customers connected via such RS may have chosen such paths as best even if 
> they have alternatives ...
>
> Thx,
> R.

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 10 Jul 2011 01:23:23 +0200

Hi Sandy,

> The owner of the advertised prefix doesn't have ownership of the next
> hops along the path. nor does it have anything to say about the
> legitimacy of next hops along the path.
>

Third party next hop (typical in IX cases) assures that the ownership of 
the next hop stays unchanged. So I would observe that this would make it 
actually easier there.

Moreover there are deployed applications which specifically mandate to 
not change next hop across AS boundaries. As example I could bring 
Inter-AS option C for L3VPNs. Note that there can be transit ASes in the 
path too. So how are we going to assure a customer of such service that 
the advertising prefix from customer site attached to AS 1, transiting 
via AS 2 and terminating at AS 3 got to the final site on the other side 
uncompromized ?

Maybe one should ask the bigger question: Is BGPSec as is being defined 
in SIDR applicable to other address families other then 1/1|2 and 2/1|2 
which still carry IP prefixes or is it out of scope ?

How about Internet as a VPN (aka Internet in a VRF scenarios) where 
internet routes may travel as vpnv4/vpnv6 updates ?

How about those address families in BGP which are designed to carry 
control plane information between domains for example: bgp flowspec or 
rt-constrain ?

I am just trying to understand if we are talking more of enhancements to 
bgp security (bgp being the protocol) or perhaps about just limiting the 
SIDR scope to build a new layer for controlling traditional Internet 
prefix propagation ?

Many thx.
R.

---

From: "Chris Hall" <[email-masked]>
Date: Sun, 10 Jul 2011 17:05:37 +0100

Sandra Murphy wrote (on Fri 08-Jul-2011 at 20:30):
...
> Section 6.6 rightly notes that if an AS decided to share its
> private key with another AS, no one outside the agreement
> could tell the difference.

As it stands, this is how a transparent route server could be
implemented.

I don't see a requirement to support transparent route servers in
draft-ietf-sidr-bgpsec-reqs :-(

Mind you, placing the RS ASN in the path might be said to violate:

  3.15 A BGPsec design MUST NOT require operators to reveal
       more than is currently revealed...

Though there's no shame in using an RS... except, perhaps, that your
larger ASes will tend not to, and may turn their noses up at those
that do.

Using an RS, IXP customers can peer with each other for the cost of
one BGP Session (or one with each local RS instance).  At some IXPs
there are several hundred RS clients.  The cost doesn't go away, but
falls on the RS, which scales as (N * N * R) -- number of clients 'N'
and average number of routes each 'R' -- that is: it scales horribly.

It would make life easier for the RS if the clients' routers were able
to do more of the work -- noting that it is vital that this does NOT
require any additional administrative effort beyond the initial
configuration, and that new RS clients are automatically connected to
all others (by default, at least).  But any change at the client end
requires some change to BGP and/or to administrative features of BGP
implementations... so good luck with that, as they say :-(

One such approach would use something like draft-walton-bgp-add-paths
(currently expired), so that the RS no longer has to make any best
path selection, but can pass all routes it has for each prefix, and
let the clients decide.  (This also solves the problem of how to allow
clients to tune the selection process in the RS.)

For BGPSEC it might be nice to push the signing out to the client:
suppose BGPSEC were extended, so that each route given to the RS
contained a list of AS Path signatures, one for each possible
destination.  This would also require a means for the RS to signal all
possible destination ASes, so that there is no need for administrators
to fiddle with their configurations.  This solves the private key
issue and has the happy property of moving work to the client --
except that they may not be quite ready to generate and send several
hundred path signatures per route !

More exotic would be to arrange for the RS to talk to a box in each
client which would provide the required signatures (inside the minimum
advertisement interval).  If that were a function of the local RPKI
Cache, then setting up a BGPSEC connection to the RS would be a little
more complicated, but once done would require no further work.  (The
request for a new signature could pass the current signatures, AS Path
and NLRI etc, so that the signing box can verify that the RS is not
asking for something it shouldn't.)

Chris

---

From: "Chris Hall" <[email-masked]>
Date: Sun, 10 Jul 2011 17:46:54 +0100

....
> :-}
....
> Having said that, I respect Randy's viewpoint (and yours -- seems

I was mostly paraphrasing the opinion which had been put to me quite
strongly.

>From where I sit, I would happily trust, say, the LINX.  But I
entirely take the point that a better system would not require me to
depend entirely on trust; and someone new to the LINX might prefer not
to.

....
> We can revise Section 6.6 to put greater emphasis on the "cons" part

I think that would be a most reasonable thing to do.

Particularly, from the RS perspective, because Proxy Signing is
(currently) how a Transparent BGPSEC RS might be implemented.  The
cons would be the basis for a case for some other solution, in the
BGPSEC protocol, or elsewhere. 

Chris