Subject: [sidr] suggested amendment to draft-ymbk-bgpsec-reqs

From: Andrei Robachevsky <[email-masked]>
Date: Fri, 01 Apr 2011 14:37:21 +0200

Hi,

I propose the inclusion of the following requirement:

3.x A BGPsec design should not decrease the performance characteristics
of the BGP, nor have a negative impact on the overall resilience of the
routing system.

Examples that I have in mind is the convergence time or a solution that
can make the global routing system more fragile (e.g. an expired
signature blacking out a significant part of the Internet). Perhaps that
should also be covered in the deployment considerations, since this
depends partly on local policy decisions.

Andrei

---

From: Doug Montgomery <[email-masked]>
Date: Fri, 01 Apr 2011 09:35:50 -0400

> of the BGP, nor have a negative impact on the overall resilience of the
"should not decrease" seems a bit literal and restrictive.   One could 
argue that no addition of a feature that put more bits on the wire could 
meet that goal.

Maybe the operative requirement is that the performance implications 
with respect to convergence be clearly defined (in an algorithmic sense 
(e.g., require 1 RSA/SHA verification per hop, and the addition of x 
bytes of new attributes per hop).

Maybe some follow up bench marking of independent implementations in the 
protocol report later would further clarify the issue.

All other characterizations of larger impacts on convergence will be 
based upon models ... and more speculative.

As for resilience, I think it also key to document what factors might 
influence resilience issues of BGPSEC operations (e.g., distribution of 
global RPKI data, etc).

One should also note that the goal of this protocol is to improve the 
resilience of the system ... ;^).

As it stands now, BGPSEC is opt-in.    So it seems that clearly 
documenting these issues is more operative than make absolute 
requirements about them.

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

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 1 Apr 2011 16:24:37 -0400 (Eastern Daylight Time)

> of the BGP, nor have a negative impact on the overall resilience of the

Could you say how strictly you would want this requirement interpreted? 
For example, I would say that not even TCP-AO has NO impact on performance 
and resilience.  Do you want the requirement to forbid TCP-AO?

--Sandy, speaking as wg co-chair

---

From: Danny McPherson <[email-masked]>
Date: Sat, 2 Apr 2011 09:04:33 -0400

> depends partly on local policy decisions.

As much as I'd love to support this, ultimately, any time you add 
integrity mechanisms to an information system you simply introduce 
more ways to fail, no?

OTOH, it's important to be aware that new externalities and/or 
dependencies are being added, and we should aim not to step all the
way back to RIPv1 scaling properties - brushing aside all that's been
learned over the past several decades.

-danny

---

From: Russ White <[email-masked]>
Date: Sat, 02 Apr 2011 13:24:16 -0400

> documenting these issues is more operative than make absolute

Does this mean BGPSEC is not designated as a standards track document?
how can a security system actually work if it's "opt in?" It sounds like
this is an area that needs some discussion around it.

:-)

Russ

---

From: Andrei Robachevsky <[email-masked]>
Date: Mon, 04 Apr 2011 12:28:51 +0200

Sandra Murphy wrote on 01-04-11 22:24:
> For example, I would say that not even TCP-AO has NO impact on
> performance and resilience.  Do you want the requirement to forbid TCP-AO?
> 

I agree with the comments on the list, it was more a strawman. How about
a more moderate requirement:

3.x A BGPsec design MUST provide analysis of the operational
considerations for deployment with respect to the impact on the
performance characteristics and the overall resilience of the routing
system. 	

This may be already implied in 3.3, but I'd like to make these two
aspects more explicit.

Andrei

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Apr 2011 10:24:10 -0400

At 1:24 PM -0400 4/2/11, Russ White wrote:
>Content-Type: multipart/signed; micalg=pgp-sha1;
>  protocol="application/pgp-signature";
>  boundary="------------enig5992EC3DE2163EED1CCB39EC"
>
>

A standards track protocol is usually mandatory to implement, but using
it is a local context determination.  I expect that's what was meant by opt-in.

Steve

---

From: Randy Bush <[email-masked]>
Date: Mon, 04 Apr 2011 12:45:46 -0700

> 3.x A BGPsec design should not decrease the performance
> characteristics of the BGP, nor have a negative impact on the overall
> resilience of the routing system.

ok.  i'll bite.  i think this is worthwhile desire.  but as an internet
routing measurement person, i have to ask

    what are the performance charastics of bgp?  what is the resilience
    of the routing system?

    what is to be measured, what are the units of measure, how are the
    measurements taken, and what are the values of these measurements in
    today's routing system?

answer even the first two, and i am sure that ripe labs will have an
answer for the rest within a week. :)

randy

---

From: Andrei Robachevsky <[email-masked]>
Date: Tue, 05 Apr 2011 13:59:55 +0200

> answer for the rest within a week. :)

I think these questions worth pondering, and I don't know the answers,
Randy. I suspect that you might know some of them. But submitted an
adapted version, hopefully more acceptable.

Andrei

---

From: Randy Bush <[email-masked]>
Date: Tue, 05 Apr 2011 06:00:07 -0700

> I think these questions worth pondering

oh, indeed.  many future great papers and phd theses lurk here.

> I don't know the answers, Randy. I suspect that you might know some of
> them.

i wish.  these are quite deep research questions at which many really
good computer scientists are barely nibbling at the edge.

as i said some years ago,

    The fact that very good computer scientists are studying the
    internet as a behavioral phenomonon should scare the hell out 
    of us.

rady

---

From: Doug Montgomery <[email-masked]>
Date: Tue, 5 Apr 2011 18:06:31 -0400

> it is a local context determination.  I expect that's what was meant by opt-in.

Thanks Steve, that is what what I meant.   

Clearly the hope (and value proposition) is that it is deployed farily ubiquitously, but the design recognizes that some parts of the net might choose not to run it, or only run part of it (simplex mode).

I have yet to see a box kicked off the net for choosing to skip a "mandatory to implement" feature.   
I think we have to deal with the market realities, no matter what the document's boiler plate says.
dougm