Subject: Re: draft-murphy-bgp-secr-03.txt
From: Yakov Rekhter <[email-masked]>
To: Sandy Murphy <[email-masked]>
Cc: [email-masked]
Date: Tue, 08 Feb 2000 10:38:15 -0800

Sandy,

> >I reiterate that if you are going to claim it is
> >*just* a protocol analysis, then you need to remove about 80% of the draft
> >as it refers to something which is neither part of the protocol nor
> 
> It's an analysis of what's there and the possible enhancements to
> the protocol.

I wonder if it could help to make progress if you would "unbundle" 
your Internet Draft into two separate Internet Drafts, the first with
the analysis part, and the second with the possible enhancements.

Yakov.

Date: Tue, 8 Feb 2000 13:21:53 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: Secure BGP -- Internet Drafts
Cc: [email-masked]
Sender: [email-masked]

>That seems unworkable.  The NLRI blocks are as large as 500 prefixes.

I think you need to talk to the SBGP guys.  First, I may have gotten
their story wrong.  Second, I'm not the person to convince.

>When
>this occurs, a subset of an NLRI block is propogated further.

Yes, and when that happens, all the original signed NLRI blocks must
accompany the subsets that are propogated.

>> now.  If the RIB's get big, is that a problem, or is it only the
>> forwarding table size that motivated aggregation?
>
>
>Yes.  That is a problem.

I'm bowing out of this - I'm not the right person to be expressing
an opinion or listening to advice.  Again, I think the BBN guys
would really want to listen to this sort of info.

>> decided upon route before sending an UPDATE to a neighbor or verify just
>> whenever you think there's a problem.  (That last one is chancy.)
>
>
>The latter allows a bad route to be installed and therefore can divert
>traffic.

Yes, exactly.  That's why I called it "chancy".  If you verify only when
you think there's a problem (or at some periodicity), then you let problems
occur and you fix them later.  About the only advantage is that you know
where the problem came from.

--Sandy

To: Sandy Murphy <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: protecting BGP routing with filters 
Date: Tue, 08 Feb 2000 13:12:10 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Sandy Murphy writes:
> I am fundamentally bothered by the claims of prefix and AS_PATH filtering.
> The claims that these filters help can only hold if:
> 
>   (1)  the filters are derived from accurate, complete and timely
>        topology information
> 
>   (2)  the filters aren't so inspecific as to be meaningless
> 
> 
> There are those who claim that (1) can be achieved by reference to the
> IRR's.  Given time and effort and mandates for allocating addresses, I can
> see that completeness might hold true at some point, for network
> prefixes.  (Any one got any data on how much of the allocated IP
> address space is represented in the IRR's?)  Timeliness would also be
> a matter of careful design and engineering.  I don't know about
> accuracy - we're relying on the same people to input data who are
> presently making mistakes in configuring their routers.
> 
> But the AS_PATH information and the transit policies require that the
> AS's publicize information closely related to their private peering
> agreements.  I have heard from several people who should know that
> there is doubt that the AS's would be willing to take that step,
> particularly as the participation in the IRR's is presently voluntary.
> That means that completeness would be difficult to achieve.
> 
> As for (2), I can see that near the edges of the internet, it might be
> possible to have specific filters on incoming routes, because the
> operators would have direct knowledge of their customer and the
> customer would have very little to say.  But if the Internet
> connectivity is at all rich, not-tree-like, then at some point away
> from the edge, an AS must be able to receive routes to most addresses
> and routes to most addresses from most peers.  In other words, the
> filters wouldn't be able to filter out much of anything.  And if the
> Internet connectivity is tree-like and not rich so that it stays
> possible to know what prefix+path you will get from each peer and to know
> from what peer you will get each prefix+path, then the Internet is
> inherently fragile.  An extremely bad attribute for a Critical
> Infrastructure.
> 
> So which is it?
> 
> --Sandy

Sandy,

The IRR is incomplete.  Not all prefixes are available in the IRR.  AS
adjacnecies are not accurately represented.

The deployment of sanity filters varies among providers.

  Some (including a few major providers) still do not filter route
  announcements from their direct customers.

  Some providers filter their own customers and prefer routes (in
  order of preference) from 1) their direct customers and 2) from
  providers that are know to filter and/or be more reliable.

  Some providers take the two steps above and (unless things have
  changed since I was last in touch with operations) also prefer
  registered routes from peers over unregistered.

This only means that registering a prefix and choosing a provider that
does a bit more filtering than less may provide some improvement in
reliability.

If you pick a provider that does no filtering at all, then a malicious
or accidental bad announcement could effectively take out you
connectivity.  If you pick a provider that does more filtering, your
connectivity to others using the same provider and other providers
that have effective filters is immune to this sort of problem.  Your
connectivity to a provider that does no filtering at all can still be
effected.

Registering prefixes in the IRR may also help depending on who is
using it these days.

Is this adequate?  IMHO - No.  In practice, it has proven workable
though occasional outage do occur so sites who's business relies
heavily or almost entirely on their connectivity (example: AOL) are
directly connected to many providers and also take steps to insure
that the providers they connect to filter *their* prefixes even if
they don't filter in general.

Curtis

Date: Tue, 8 Feb 2000 13:09:11 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: draft-murphy-bgp-secr-03.txt
Cc: [email-masked]
Sender: [email-masked]

>I reiterate that if you are going to claim it is
>*just* a protocol analysis, then you need to remove about 80% of the draft
>as it refers to something which is neither part of the protocol nor

It's an analysis of what's there and the possible enhancements to
the protocol.

>computationally feasible.

I dispute that it is not computationally feasible.

>why are operational solutions inadmissable

Because they do not make the protocol secure, they make the network
operation robust.  Like "don't use clear text passwords", etc.

--Sandy

To: Sandy Murphy <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: Secure BGP -- Internet Drafts 
Date: Tue, 08 Feb 2000 12:52:57 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Sandy Murphy writes:
> >> > The algorithm cost is based on prefixes, if the cost of the computation
> >> > based on prefix growth is less than Moore's law, there isn't a problem.
> >> >
> >> 
> >> It is actually proportional to the number of prefixes multiplied by the
> >> average AS path length as the computations are carried out for each AS in
> >> the path.
> >> 
> >> Ben
> 
> >Minor point - Its the number of unique prefix and advertising AS
> >advertised to the router via EBGP times the average AS path length.
> >...
> >The AS path is the same for the whole BGP update, but
> >prefixes must be signed individually.
> 
> Overall, I don't know that it makes a difference in the magnitude of
> the numbers - but I think SBGP signs the NLRI *block*, not each
> individual NLRI.  That means that if you choose just one NLRI from a
> block to advertise, you have to forward the original NLRI block, too.
> (And Charlie and Luis can bash me on the list if I've got this wrong.)
> Fewer signatures, more signed data to be passed - my back of the
> envelope said that this wins most times unless the NLRI blocks or the
> AS_PATHs get big.

That seems unworkable.  The NLRI blocks are as large as 500 prefixes.
BGP implementations currently repack the NLRI each time they are
advertised as they currently do not maintain any record of how they
were packed on the way in.

It is common for another AS Path to provide a better path to a subset
of routes (some examples are dual homed customers such as research
networks that also have connectivity to a commercial service).  When
this occurs, a subset of an NLRI block is propogated further.

> >Aggregation is problematic since signatures cannot be aggregated.
> 
> Yes, that's true.
> 
> I was listening to Steve Kent talk about SBGP and suddenly realized
> one of their points - that the *forwarding* table is not affected by
> the signatures that have to be carried.  The fact that all the
> un-aggregated signatures have to be carried forward past an
> aggregation point means that the RIB's will not decrease in size, but
> the forwarding table will still decrease and just as much as it does
> now.  If the RIB's get big, is that a problem, or is it only the
> forwarding table size that motivated aggregation?

Yes.  That is a problem.

> >If they are
> >kept in deaggregated form, this begs the question as to whether the
> >router needs to verify the signatures chains within the aggregate and
> >what it does if some are valid but some are not.
> 
> I think that the SBGP guys would say that all the signatures have
> to verify - each is attesting to some delegation of authority, so if any
> one does not work, you do not have a chain of authority established.
> 
> There's also the point of when you do the verification - verify every
> incoming UPDATE before doing the decision procedure or verify the
> decided upon route before sending an UPDATE to a neighbor or verify just
> whenever you think there's a problem.  (That last one is chancy.)

The latter allows a bad route to be installed and therefore can divert
traffic.

> --Sandy

Curtis

Reply-To: "Benjamin Black" <[email-masked]>
From: "Benjamin Black" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-murphy-bgp-secr-03.txt
Date: Tue, 8 Feb 2000 09:28:40 -0800
Sender: [email-masked]

Yes, I noticed the brief comments buried in the midst of all the AS path
signature discussion.  I reiterate that if you are going to claim it is
*just* a protocol analysis, then you need to remove about 80% of the draft
as it refers to something which is neither part of the protocol nor
computationally feasible.  If you are going to allow for presentation of
"solutions" to protocol weaknesses, such as the numerous mentions of
signature schemes, then why are operational solutions inadmissable?

Ben

> >All the more reason for it to have been mentioned in regards to BGP
> >security.
> >
> >
> >Ben
> >
> >> > Please refer
> >> >to RFC2725 and draft-ietf-rps-dist-06.txt.
> >>
> >> You might want to note that I am an author of rfc2725.
> >>
> >> --Sandy
> >>
>
> See section 3.6 "Rely on Registries", page 13 and section 4.5 "Rely on
> Registries", page 15 and reference [5] to the Routing Policy System
Security
> draft, page 17.
>
> --Sandy
>
>

Date: Tue, 8 Feb 2000 12:17:07 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: draft-murphy-bgp-secr-03.txt
Cc: [email-masked]
Sender: [email-masked]

>All the more reason for it to have been mentioned in regards to BGP
>security.
>
>
>Ben
>
>> > Please refer
>> >to RFC2725 and draft-ietf-rps-dist-06.txt.
>>
>> You might want to note that I am an author of rfc2725.
>>
>> --Sandy
>>

See section 3.6 "Rely on Registries", page 13 and section 4.5 "Rely on
Registries", page 15 and reference [5] to the Routing Policy System Security
draft, page 17.

--Sandy

Reply-To: "Benjamin Black" <[email-masked]>
From: "Benjamin Black" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: draft-murphy-bgp-secr-03.txt
Date: Tue, 8 Feb 2000 09:05:24 -0800
Sender: [email-masked]

All the more reason for it to have been mentioned in regards to BGP
security.

Ben

> > Please refer
> >to RFC2725 and draft-ietf-rps-dist-06.txt.
>
> You might want to note that I am an author of rfc2725.
>
> --Sandy
>

Date: Tue, 8 Feb 2000 11:40:00 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: draft-murphy-bgp-secr-03.txt
Cc: [email-masked]
Sender: [email-masked]

> Please refer
>to RFC2725 and draft-ietf-rps-dist-06.txt. 

You might want to note that I am an author of rfc2725.

--Sandy

Reply-To: "Benjamin Black" <[email-masked]>
From: "Benjamin Black" <[email-masked]>
To: "Sandy Murphy" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-murphy-bgp-secr-03.txt
Date: Mon, 7 Feb 2000 20:34:27 -0800
Sender: [email-masked]

> Let me say first that my purpose in writing this draft was to answer
> two questions:
>    Is BGP a secure protocol? and
>    What could we do to enhance the protocol to make it secure?

Introduction of undeployed and incompletely specified "enhancements" rather
than coverage of *existing* mechanisms would seem of limited utility.

> This is intended as a record of the knowledge base of the answers to
> those two questions, not a suggestion that any of the various
> directions be taken.  If in future the working group decided to pursue
> making BGP secure, this draft would be a starting point for ideas.
>

If this is the case, then it is essential that deployed security mechanisms
be covered.

> The operational mechanisms you mention are attempts to compensate for
> the vulnerabilities in BGP, not to correct the vulnerabilities.  So
> they do not belong in an analysis of BGP security.  I would think that
> they *do* belong in the "Applicability Statement" that is one of the
> mandated suite of RFC's that must be written about any protocol.  I
> expect that the document might say "As shown in the xxx RFC, BGP is
> vulnerable in various ways, but the known enhancements to BGP that
> would correct those vulnerabilities are expensive.  Operators would be
> wise to implement some set of the following procedures:"
>
> I have seen presentations about prefix filtering at NANOG, etc, but I
> am not assured that those operational mechanisms are scalable and
> effective against deliberate attack through a BGP participant.  If
> they are not, then I would say that they provide robustness or fault
> tolerance or some similar statistical attribute, but not security.
>
> Furthermore, the prefix filtering does not address at all the problems
> that result from falsification of the AS_PATH.  A bogus AS_PATH could
> overwhelm networks just as easily as a bogus network origination.
>

Directly generating policy from a secure registry provides for both prefix
and AS path filtering.  In another e-mail you express concerns regarding the
accuracy and timeliness of the information in the registries.  Please refer
to RFC2725 and draft-ietf-rps-dist-06.txt.  If an entity enters inaccurate
information for its own prefixes, it only impacts its own reachability.  If
an entity allows its registry information to become out of date, it only
impacts its own reachability.  This is exactly the situation desired: the
source of policy information is a secure repository and the policy is a
direct reflection of that repository.

I strongly encourage you to familiarize yourself with all the relevant RFCs,
drafts, and common practice before making arbitrary judgements on what can
and can't be included in an information draft on the security of BGP.

>
> >The mechanisms I describe do not belong in the protocol.
>
> And hence do not belong in a discussion of security enhancements to the
> protocol.
>
> >They are simply
> >common practice and common practice is often documented in an RFC other
than
> >the one describing the original protocol.
>
> OK - but not in this one.
>
> >Agreed.  This is why I pointed out the numerous *deployed* solutions for
the
> >problems presented
>
> I think I disagree that the operational mechanisms should be characterized
> as "solutions".
>

If operational mechanisms can cause the problem to cease to exist, then they
would appear to solve the problem.  I am open to other definitions of
solutions.

> >My comment regarding the ORIGIN attribute was that the vulnerability is
more
> >(however slightly) than what you believed.
>
> OK, I'll strengthen that part.
>
> >This is the sort of thing that *should* be discussed in
> >a draft regarding security.
>
> In a draft discussing secure operations, yes, but not in a draft
> discussing the protocol's security.  Otherwise, all sorts of wisdom
> regarding secure operation would need to be included.
>

If you are going to cover the *actual* weaknesses of the protocol, then do
so.  However, that means you have eliminated the introduction of *new*
protocol mechanisms as they do not address flaws in the *existing* protocol.

> About the AS_PATH prepending - both you and Randy say that I must have
> misunderstood comments about adding multiple copies of one's AS
> number.  I really thought that route servers had been brought up as an
> example of places where prepending need not occur, but since noone has
> spoken up I'll simply take what you and Randy and the spec say as
> both gospel and real life.
>

I encourage you to read RFC1863 as it directly addresses your questions
about the behavior of route servers.

Ben

Date: Mon, 7 Feb 2000 16:45:18 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: protecting BGP routing with filters
Cc: [email-masked]
Sender: [email-masked]

I am fundamentally bothered by the claims of prefix and AS_PATH filtering.
The claims that these filters help can only hold if:

  (1)  the filters are derived from accurate, complete and timely
       topology information

  (2)  the filters aren't so inspecific as to be meaningless

There are those who claim that (1) can be achieved by reference to the
IRR's.  Given time and effort and mandates for allocating addresses, I can
see that completeness might hold true at some point, for network
prefixes.  (Any one got any data on how much of the allocated IP
address space is represented in the IRR's?)  Timeliness would also be
a matter of careful design and engineering.  I don't know about
accuracy - we're relying on the same people to input data who are
presently making mistakes in configuring their routers.

But the AS_PATH information and the transit policies require that the
AS's publicize information closely related to their private peering
agreements.  I have heard from several people who should know that
there is doubt that the AS's would be willing to take that step,
particularly as the participation in the IRR's is presently voluntary.
That means that completeness would be difficult to achieve.

As for (2), I can see that near the edges of the internet, it might be
possible to have specific filters on incoming routes, because the
operators would have direct knowledge of their customer and the
customer would have very little to say.  But if the Internet
connectivity is at all rich, not-tree-like, then at some point away
from the edge, an AS must be able to receive routes to most addresses
and routes to most addresses from most peers.  In other words, the
filters wouldn't be able to filter out much of anything.  And if the
Internet connectivity is tree-like and not rich so that it stays
possible to know what prefix+path you will get from each peer and to know
from what peer you will get each prefix+path, then the Internet is
inherently fragile.  An extremely bad attribute for a Critical
Infrastructure.

So which is it?

--Sandy

Date: Mon, 7 Feb 2000 16:00:10 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: Secure BGP -- Internet Drafts
Cc: [email-masked]
Sender: [email-masked]

>> > The algorithm cost is based on prefixes, if the cost of the computation
>> > based on prefix growth is less than Moore's law, there isn't a problem.
>> >
>> 
>> It is actually proportional to the number of prefixes multiplied by the
>> average AS path length as the computations are carried out for each AS in
>> the path.
>> 
>> Ben

>Minor point - Its the number of unique prefix and advertising AS
>advertised to the router via EBGP times the average AS path length.
>...
>The AS path is the same for the whole BGP update, but
>prefixes must be signed individually.

Overall, I don't know that it makes a difference in the magnitude of
the numbers - but I think SBGP signs the NLRI *block*, not each
individual NLRI.  That means that if you choose just one NLRI from a
block to advertise, you have to forward the original NLRI block, too.
(And Charlie and Luis can bash me on the list if I've got this wrong.)
Fewer signatures, more signed data to be passed - my back of the
envelope said that this wins most times unless the NLRI blocks or the
AS_PATHs get big.

>Aggregation is problematic since signatures cannot be aggregated.

Yes, that's true.

I was listening to Steve Kent talk about SBGP and suddenly realized
one of their points - that the *forwarding* table is not affected by
the signatures that have to be carried.  The fact that all the
un-aggregated signatures have to be carried forward past an
aggregation point means that the RIB's will not decrease in size, but
the forwarding table will still decrease and just as much as it does
now.  If the RIB's get big, is that a problem, or is it only the
forwarding table size that motivated aggregation?

>If they are
>kept in deaggregated form, this begs the question as to whether the
>router needs to verify the signatures chains within the aggregate and
>what it does if some are valid but some are not.

I think that the SBGP guys would say that all the signatures have
to verify - each is attesting to some delegation of authority, so if any
one does not work, you do not have a chain of authority established.

There's also the point of when you do the verification - verify every
incoming UPDATE before doing the decision procedure or verify the
decided upon route before sending an UPDATE to a neighbor or verify just
whenever you think there's a problem.  (That last one is chancy.)

--Sandy

Date: Mon, 7 Feb 2000 15:39:54 -0500 (EST)
From: Sandy Murphy <[email-masked]>
To: [email-masked]
Subject: Re: draft-murphy-bgp-secr-03.txt
Cc: [email-masked]
Sender: [email-masked]

[Sorry for the long delay in responding - I've been mostly on travel
for the last two weeks (when not snowed in).]

Let me say first that my purpose in writing this draft was to answer
two questions:
   Is BGP a secure protocol? and
   What could we do to enhance the protocol to make it secure?
This is intended as a record of the knowledge base of the answers to
those two questions, not a suggestion that any of the various
directions be taken.  If in future the working group decided to pursue
making BGP secure, this draft would be a starting point for ideas.

Did you miss the fact that this is intended to be an Informational
RFC?

The operational mechanisms you mention are attempts to compensate for
the vulnerabilities in BGP, not to correct the vulnerabilities.  So
they do not belong in an analysis of BGP security.  I would think that
they *do* belong in the "Applicability Statement" that is one of the
mandated suite of RFC's that must be written about any protocol.  I
expect that the document might say "As shown in the xxx RFC, BGP is
vulnerable in various ways, but the known enhancements to BGP that
would correct those vulnerabilities are expensive.  Operators would be
wise to implement some set of the following procedures:"

I have seen presentations about prefix filtering at NANOG, etc, but I
am not assured that those operational mechanisms are scalable and
effective against deliberate attack through a BGP participant.  If
they are not, then I would say that they provide robustness or fault
tolerance or some similar statistical attribute, but not security.

Furthermore, the prefix filtering does not address at all the problems
that result from falsification of the AS_PATH.  A bogus AS_PATH could
overwhelm networks just as easily as a bogus network origination.

>The mechanisms I describe do not belong in the protocol.

And hence do not belong in a discussion of security enhancements to the
protocol.

>They are simply
>common practice and common practice is often documented in an RFC other than
>the one describing the original protocol.

OK - but not in this one.

>Agreed.  This is why I pointed out the numerous *deployed* solutions for the
>problems presented

I think I disagree that the operational mechanisms should be characterized
as "solutions".

>My comment regarding the ORIGIN attribute was that the vulnerability is more
>(however slightly) than what you believed.

OK, I'll strengthen that part.

>This is the sort of thing that *should* be discussed in
>a draft regarding security.

In a draft discussing secure operations, yes, but not in a draft
discussing the protocol's security.  Otherwise, all sorts of wisdom
regarding secure operation would need to be included.  

About the AS_PATH prepending - both you and Randy say that I must have
misunderstood comments about adding multiple copies of one's AS
number.  I really thought that route servers had been brought up as an
example of places where prepending need not occur, but since noone has
spoken up I'll simply take what you and Randy and the spec say as
both gospel and real life.

--Sandy

To: Charles Lynn <[email-masked]>
Cc: Benjamin Black <[email-masked]>, Danny McPherson <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: S-BGP performance paper - was: Re: Secure BGP -- Internet Drafts 
Date: Fri, 04 Feb 2000 12:58:50 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Charles Lynn writes:
> Ben,
> 
> > You reference a paper to be published next month which specifically
> > addresses the performance issue.  Can this be provided to the group?
> 
> Yes, I now have permission to make the S-BGP NDSS 2000 paper available.
> The URL of the paper is 
> 	http://www.ir.bbn.com/projects/sbgp/ndss00.S-BGP.ps
> There is a link to it from the S-BGP home page
> 	http://www.ir.bbn.com/projects/sbgp
> 
> Comments are welcome, especially on the "underlying statistics" ...
> 
> Danny,
> 
> > I'll gladly provide anyone interested in performing these simulations
> > with a perspective of typical number of iBGP/eBGP peers and routes
> > your simulations.
> 
> That information would be appreciated.  The most quantitative data we
> have for peers is from BGP traffic recorded by Merit, but that misses
> private peerings and doesn't really have show iBGP sessions.  We used
> actual eBGP peering sessions with the three ISPs that responded to my
> request at the IDR WG session but they might not be diverse enough to
> be representative of the whole Internet.
> 
> Suggestions for additional experiments that lead to convincing results
> are also welcome.
> 
> Charlie

Charlie,

Two figures in your paper strike me as significant.  In Table 2 you cite:

  1,426 updates per day

In section 5.6.2 it appears as though the table (not numbered) tells
us that using SHA-1 and 1024 bit DSA we'd have:

  139.9 CPU minutes/day steady state

If that is 2+ CPU hours per 24 hour day per peer providing 1,426
updates per day, what does this mean if either your router has 50
peers or a bad day.  Looking at past history at IPMA
(http://www.merit.edu/ipma/instability/) we see:

  the host zounds.merit.edu is incredibly slow ... not responding

If it were working I suspect you'd still see peak days were the number
of updates were much higher and certainly peak hours where the update
rate for the hour exceeded the CPU processing ability for that hour.

  salamanders are very slow animals ... but I finally got a reply

  an empty page and nicely formated timeout message ... Craig?  Ahba?  

In practice not all 50 peers will send full routing.  These routers
have outbound filters that reduce what is sent to a subset fo full
routes.  People who make routers must build equipment that can
withstand worst case scenarios such as some of the peers accidentally
dropping their outbound filter policies and leaving the routers that
way.  We also have to consider what happesn during peaks and creating
15 to 20 minute CPU backlogs would not be acceptable.

Therefore, your proposal has limited applicability and may not be at
all applicable to use by gateway routers in the Internet at least
without a very significant boost in CPU power.  Again, I don't think
this should prevent publication of your i-d as informational or
experimental and maybe you'll even get someone to try the experiment.
If it suceeds, then the IDR WG can revisit this.

It almost seems like the conclusion of you paper is that without
cryptographic hardware the proposal is infeasible or at least
impractical.  You didn't mention what sort of speedup you could expect
relative to the P/Pro-200 that you used.  (Clearly you could already
get a factor of as much as 2-3 just using a newer processor).

If I've misinterpreted your paper, please let me know.

Curtis

Date:     Thu, 3 Feb 100 16:04:12 EST
From: Charles Lynn <[email-masked]>
To: Benjamin Black <[email-masked]>, Danny McPherson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject:  S-BGP performance paper - was: Re:  Secure BGP -- Internet Drafts
Sender: [email-masked]

Ben,

> You reference a paper to be published next month which specifically
> addresses the performance issue.  Can this be provided to the group?

Yes, I now have permission to make the S-BGP NDSS 2000 paper available.
The URL of the paper is 
	http://www.ir.bbn.com/projects/sbgp/ndss00.S-BGP.ps
There is a link to it from the S-BGP home page
	http://www.ir.bbn.com/projects/sbgp

Comments are welcome, especially on the "underlying statistics" ...

Danny,

> I'll gladly provide anyone interested in performing these simulations
> with a perspective of typical number of iBGP/eBGP peers and routes
> your simulations.

That information would be appreciated.  The most quantitative data we
have for peers is from BGP traffic recorded by Merit, but that misses
private peerings and doesn't really have show iBGP sessions.  We used
actual eBGP peering sessions with the three ISPs that responded to my
request at the IDR WG session but they might not be diverse enough to
be representative of the whole Internet.

Suggestions for additional experiments that lead to convincing results
are also welcome.

Charlie

Reply-To: "Benjamin Black" <[email-masked]>
From: "Benjamin Black" <[email-masked]>
To: "Charles Lynn" <[email-masked]>, "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-murphy-bgp-secr-03.txt
Date: Tue, 1 Feb 2000 19:28:29 -0800
Sender: [email-masked]

As I outlined in detail in several other posts, this draft offers little in
the way of BGP protocol analysis and even less for proposed solutions.  I
see no reason to accept it as a WG document.

Ben

> Yakov,
>
> > I'd like to get your opinion on accepting draft-murphy-bgp-secr-03.txt
> > as an IDR WG document with the ultimate goal of publishing it as
> > an Informational RFC. Please comment on this within the next 2 weeks.
>
> I think that the draft should be accepted as an IDR WG document with
> the intent of getting it published in the near term, even if that
> means dividing it into separate vulnerability and proposed solution
> mechanisms documents.  As has been noted on the list, defining a few
> terms might make the document useful to a larger community that may
> not be familiar with special connotations those terms have in the BGP
> context.
>
> Charlie
>
>

Date:     Tue, 1 Feb 100 17:06:54 EST
From: Charles Lynn <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject:  Re:  draft-murphy-bgp-secr-03.txt
Sender: [email-masked]

Yakov,

> I'd like to get your opinion on accepting draft-murphy-bgp-secr-03.txt
> as an IDR WG document with the ultimate goal of publishing it as
> an Informational RFC. Please comment on this within the next 2 weeks.

I think that the draft should be accepted as an IDR WG document with
the intent of getting it published in the near term, even if that
means dividing it into separate vulnerability and proposed solution
mechanisms documents.  As has been noted on the list, defining a few
terms might make the document useful to a larger community that may
not be familiar with special connotations those terms have in the BGP
context.

Charlie