Subject: RE: [RPSEC] Re: draft-convery-bgpattack-00

From: [email-masked]
Date: Wed, 6 Nov 2002 10:42:41 -0500 (EST)

>IMHO - "Security requirements" that force Internet capital spending and
>network wide maintenance windows to deploy are not going to be adopted by
>the operations community.

Not a surprising development and reminiscent of the auto manufacturers'
stance on seat belts, crash resistent bumpers, air bags, ...  Those whose
focus is the bottom line always want to be shown a financial incentive.
"How about 'survival'?" seems to be unpersuasive.

"network wide maintenance windows" - you mean the need to have recourse
to a registry of some sort?  Or the need to deploy the protections over the
whole network?  Or something else?

--Sandy
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 6 Nov 2002 17:38:59 +0100 (CET)

> "How about 'survival'?" seems to be unpersuasive.

Routers are a lot like regular computers in many ways, but you can only
expect to sell a very small number compared to computers. I'm not a
router builder but I think that's the reason why router CPUs are so slow
compared to those of regular computers: the design costs to keep up with
the latest CPU technology would be too high.

As far as I can tell, verifying a signature takes in the order of a
millisecond on a decent CPU. So with 115,000 routes in the global
routing table, that's 2 minutes to initialize BGP, assuming one
signature must be checked per route. I don't think this is acceptable,
especially not considering router CPUs may be slower, there is other
processing to do as well and the expected growth of the global routing
table. This means routers must be equipped with crypto modules.

Then there is memory. There are still many routers in production that
are already in trouble memory-wise as their design allows only 32, 64 or
128 MB and a Cisco needs 256 MB to comfortably run BGP. I've tried to
add up all the extra fields but I couldn't be sure how much of what goes
where, but it looks like S-BGP will take at least twice the memory of
regular BGP.

This means some routers must be replaced completely and all others need
hardware upgrades. So expect resistance from the people who have to pay
the bill. Especially if there is so much of a byte wasted in your packet
formats, or there is a place where crypto is used when the same result
could be obtained without it.

Also note that the perceived need for more security in BGP can't be all
that high, as we can tell by the level of MD5 option deployment.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 6 Nov 2002 12:24:41 -0500

> "How about 'survival'?" seems to be unpersuasive.

The usual incentive in that case was laws and lawsuits.
Do we really want to go there?

-- 
Jeff Haas 
NextHop Technologies

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Nov 2002 17:07:42 -0500

Iljitsch,

>the latest CPU technology would be too high.

The performance of the CPU used for BGP varies from model to model 
and from vendor to vendor.

>table. This means routers must be equipped with crypto modules.

We realized long ago that startup transients could be a serious 
timing concern, and so we have suggested that routers destined to 
support S-BGP would ideally have non-volatile storage sufficient to 
hold a recent copy of the RAs, as well as the AAs and PKI data. Few 
(if any) routers deployed today have this cap[ability, but it would 
be cheap to provide in the future, e.g., flash memory prices are 
fairly low even today.

>where, but it looks like S-BGP will take at least twice the memory of

Again, no argument that currently deployed routers would not 
generally have sufficient memory to hold all the RAs if everyone ran 
S-BGP, but then these routers would probably no longer be in use by 
the time everybody would be ready to run S-BGP. The factors (to first 
order) that determine the extra memory requirements under S-BGP are 
the number of ADJ-RIBs the router holds, the number of routes in the 
RIBs, and the average path length for the routes. The total memory 
requirement is a function of these factors, plus the extent to which 
S-BGP is deployed, i.e., the fraction of routes that are S-BGP 
protected. In any case, we're not talking about more memory than my 
laptop and desktop have, and the costs are not great, but you are 
right that most routers in use today simply do not have the ability 
to support enough memory, although some do. But, as noted above, the 
initial stages of incremental deployment would not need as much extra 
memory as full deployment.

>could be obtained without it.

Yes, routers would need to be replaced over time, but routers are 
replaced over time anyway, so the question is in part one of timing, 
and incremental deployment is, by definition, staged over time. 
Also, it would be possible to use ancillary devices with multi-hop 
BGP to avoid a "fork lift upgrade" for some routers, if one can 
tolerate managing the extra boxes.

Steve

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 07 Nov 2002 22:10:36 -0500

What I see in S-BGP and this discussion is:

1) An approach that attempts to comprehensively provide security for BGP
2) An approach that for deployment probably requires significant 
enhancements in the actual routing hardware (storage, increased memory, 
crypto hardware).

It seems this overlooks several things:
A) The indications are that operators are not interested in (or possibly 
even capable of) deploying solutions with this complexity
B) We could probably get a lot of coverage (but not as complete) with a 
much simpler solution or set of solutions.
C) Securing BGP this carefully when the rest of the infrastructure is 
completely insecure seems almost counter-productive.

Note that currently many operators do not deploy source address filtering, 
or even martian address filtering with their customers.  And that is only 
the tip of the iceberg of simple things that need to be done.  It would 
seem that whatever energy it would take to even begin serious development 
and deployment of S-BGP could be much better spent getting some of the 
simple steps that are necessary deployed.  Then we could examine again to 
determine what makes sense to do next based on that experience.

Yours,
Joel M. Halpern

At 05:07 PM 11/7/2002 -0500, Stephen Kent wrote:
>The performance of the CPU used for BGP varies from model to model and 
>from vendor to vendor.
>
>We realized long ago that startup transients could be a serious timing 
>concern, and so we have suggested that routers destined to support S-BGP 
>would ideally have non-volatile storage sufficient to hold a recent copy 
>of the RAs, as well as the AAs and PKI data. Few (if any) routers deployed 
>today have this cap[ability, but it would be cheap to provide in the 
>future, e.g., flash memory prices are fairly low even today.
>
>Again, no argument that currently deployed routers would not generally 
>have sufficient memory to hold all the RAs if everyone ran S-BGP, but then 
>these routers would probably no longer be in use by the time everybody 
>would be ready to run S-BGP. The factors (to first order) that determine 
>the extra memory requirements under S-BGP are the number of ADJ-RIBs the 
>router holds, the number of routes in the RIBs, and the average path 
>length for the routes. The total memory requirement is a function of these 
>factors, plus the extent to which S-BGP is deployed, i.e., the fraction of 
>routes that are S-BGP protected. In any case, we're not talking about more 
>memory than my laptop and desktop have, and the costs are not great, but 
>you are right that most routers in use today simply do not have the 
>ability to support enough memory, although some do. But, as noted above, 
>the initial stages of incremental deployment would not need as much extra 
>Yes, routers would need to be replaced over time, but routers are replaced 
>over time anyway, so the question is in part one of timing, and 
>incremental deployment is, by definition, staged over time. Also, it would 
>be possible to use ancillary devices with multi-hop BGP to avoid a "fork 
>lift upgrade" for some routers, if one can tolerate managing the extra boxes.
>
>Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 8 Nov 2002 10:35:20 -0500

Joel,

>1) An approach that attempts to comprehensively provide security for BGP

yes

>enhancements in the actual routing hardware (storage, increased 
>memory, crypto hardware).

in the long run yes, but maybe not for initial, incremental 
deployment because, by definition, there are fewer entries with RAs 
and thus less space is required in RIBs and fewer sigs to generate or 
check, etc.

>A) The indications are that operators are not interested in (or 
>possibly even capable of) deploying solutions with this complexity

agreed, but at least in the U.S. there is an increased focus on 
infrastructure security, and Richard Clark has hinted that if ISPs do 
not do a better job, the Government may "help"

>B) We could probably get a lot of coverage (but not as complete) 
>with a much simpler solution or set of solutions.

Do you have a specific example in mind? So far we have few, if any 
proposals that have been well analyzed re the security they provide, 
so I find it a bit hard to understand how you can confidently make 
this statement. Also, one needs to have a metric by which you can 
characterize the extent of "coverage" in order to compare two 
security proposals. What metric do you envision?

>C) Securing BGP this carefully when the rest of the infrastructure 
>is completely insecure seems almost counter-productive.

What "rest of the infrastructure" do you have in mind? Routing is 
separate from DNS, for example, in terms of what attacks can do, so 
it is justifiable to pursue securing these independently. Also, the 
design of S-BGP is such that it protects the set of ISPs who use it 
from false advertisements about the parts of the address space by the 
ISPs who do not use it. So, it offers incremental benefits even 
without full deployment.

>Note that currently many operators do not deploy source address 
>filtering, or even martian address filtering with their customers. 
>And that is only the tip of the iceberg of simple things that need 
>to be done.  It would seem that whatever energy it would take to 
>even begin serious development and deployment of S-BGP could be much 
>better spent getting some of the simple steps that are necessary 
>deployed.  Then we could examine again to determine what makes sense 
>to do next based on that experience.

There is a difference between approaches to security that rely on 
other ISPs to do the right thing, and approaches that let you know if 
other ISPs are doing the right thing. S-BGP falls into the latter 
category and thus is more resistant to benign failures and attacks 
against internal ISP route management components or procedures, vs. 
schemes that rely on ISPs doing local source address filtering, for 
example. Yes, there are other things ISPs could be doing to make life 
better, but these measures are not very resistant to many forms of 
attacks and they represent considerable management burdens for ISPs. 
So in part the question is whether one should devote effort to 
halfway measures, or devote more effort to more comprehensive 
measures.

Steve

---

From: Randy Bush <[email-masked]>
Date: Fri, 08 Nov 2002 09:21:05 -0800

> filtering, or even martian address filtering with their
> customers.  And that is only the tip of the iceberg of simple
> things that need to be done.  It would seem that whatever energy
> it would take to even begin serious development and deployment of
> S-BGP could be much better spent getting some of the simple steps
> that are necessary deployed.  Then we could examine again to

what this analysis omits is what we will have to do in a month or
three years when we get _serious_ widespread routing attacks [0].
as serious defense will, as you well point out, take some time to
deploy, it seems prudent to start now, rather than have a large
window of major problems while we deploy too late.

randy

---

[0] - note that we have already seen real non-trivial routing
      attacks.  folk just don't talk about them in public.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 8 Nov 2002 23:52:23 +0100 (CET)

> even capable of) deploying solutions with this complexity

Good point. Also, this is very much a double edged sword: on the one
hand, the expensive crypto checks validate that what's in the routing
tables is good, but on the other hand they'll keep out stuff, and
certainly not all of what they'll keep out will be bad. If I look at the
way routing registry entries are maintained today, I expect the first
few networks that implement this will suffer from noticably degraded
connectivity to the rest of the world.

> much simpler solution or set of solutions.

Agree. I think soBGP is much better than S-BGP in this regard, but both
of them are stuck on a track that I think is wrong for this: the source
provides information to the router, and the router validates this
information using cryptographic means. This is a good approach if the
information the source will be providing can't be checked by other
means. However, that is not the case here: it is possible to collect the
information about what the source may be announcing beforehand, and then
simply check the actual announcement against this information. This way
the routers don't need to do any crypto.

> Note that currently many operators do not deploy source address filtering,

Which is indeed a big problem as it makes very hard to trace DoS attacks
possible. These happen every day, and many ISPs don't do very little to
stop it. Routing attacks are rare enough that I've never heard anyone
say they encountered one. I don't doubt Randy's remark that there have
been some, but the fact that the victims don't want to talk about it
makes me assume the attacks could probably have stopped using today's
technology.

However, just because there is problem A doesn't mean you shouldn't do
anything about problem B. It's not like work on routing security will
take away time from installing anti-spoofing filters.

> or even martian address filtering with their customers.

Martian filters aren't a good idea as they remove some symptoms but not
the cause. If someone doesn't filter, I like seeing those packets from
192.168.0.0/16 to inform me of this fact.

Iljitsch

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 8 Nov 2002 23:55:00 +0100 (CET)

On Fri, 8 Nov 2002, Stephen Kent wrote:

> example.

Source address filtering can be done in other places than just the
customer edge. It is possible to do this on peering interfaces as well,
if done with care. Unfortunately, it can't be done on transit
interfaces. So the tier-1 ISPs (who get all their traffic from peering)
should step up to the plate and start doing this to protect the rest of
us.

Iljitsch

---

From: Stephen Kent <[email-masked]>
Date: Fri, 8 Nov 2002 18:21:51 -0500

>should step up to the plate and start doing this to protect the rest of

I realize that one can filter other than at the edge, but it gets 
harder to do it the further one goes away from the edge, with transit 
interfaces being the agreed upon limiting case. Your last sentence 
conflicts with my observation about the undesirability of relying on 
others to protect you, as far as security goes.

Its somewhat analogous to living in an apartment building; you can 
lock your own door to keep out unwanted visitors, or you can rely on 
all your fellow apartment dwellers to not loose their keys and to not 
buzz in bad visitors.

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 9 Nov 2002 18:04:03 +0100 (CET)

> all your fellow apartment dwellers to not loose their keys and to not

You should be able to rely on the door man to keep people out who are
recognizable as undesirable elements. After all, that's what you pay
for.

We all (directly or indirectly) pay the tier-1 networks so it is
reasonable to ask them to do anti-spoofing filtering on their peering
interfaces, for the exact reason you mention: expecting all ISPs to
filter their customers is the short road to disappointment.

---

From: Charles Lynn <[email-masked]>
Date: Sun, 10 Nov 2002 13:38:26 -0500 (EST)

Folks,

I think that Iljitsch's response to Joel and his observations suggest
possible requirements for any security solutions that the group may
generate.  Here are some candidates, interspersed with recent
motivating remarks.  What other requirements would folks like to
propose?

> certainly not all of what they'll keep out will be bad.

Do folks think that the false positives would be limited to one-time
events at the beginning of an ISP's learning curve, or an ongoing
operational challenge?

Might the following proposed requirements address this issue?

Proposed Requirement:
    There must be a way for an ISP to evaluate their security
    mechanisms and configurations in both a laboratory setting and in
    the live Internet without impacting any router's Decision Process.

Proposed Requirement:
    There must be an automated mechanism that allows other ISPs to
    determine whether or not a given ISP/customer/whoever's routes
    should be rejected if a security mechanisms detect a problem.

Proposed Requirement:
    Once the mechanism (posited in the previous paragraph) has been
    turned on by an ISP, there must be a way to turn it back off.  The
    allowed time interval between when it is turned back off and when
    every other ISP ceases to make routing decisions base on the
    countermeasures information must be less than <some unit of time,
    TBD>.

> If I look at the way routing registry entries are maintained today,

Do folks think that there is a viable way to address this issue, so
that the information in the routing registry can be relied upon (after
some TBD date in the future)?

> I expect the first few networks that implement this will suffer from
> noticeably degraded connectivity to the rest of the world.

I think that this is an over generalization; it probably depends on
whatever solutions are eventually adopted :-).  There is the granularity
of protection issue to consider.  Is there a ...

Proposed Requirement:
    Security solutions must allow a granularity of protection at the
    level of an individual prefix.

Proposed Requirement:
    Any solution must allow for the co-existence of both protected and
    non-protected information, and the authoritative source of the
    information must be able to control whether or not the information
    is to be considered authentic.

Proposed Requirement:
    The (unauthorized?) removal of protection information by a third
    party must be detectable.

What do folks think should happen if tampering is detected?
Should the route be rejected?
Only used if no other tamper-free route is available?
Something else?

> simply check the actual announcement against this information.

You are correct that the routers do not need to perform any crypto on
the raw origination information provided by the source; the NOCs can
do that once on behalf of all the routers in the AS.  In fact that is
exactly what S-BGP does for the relatively static authorized
originating AS information.  Generalizing a bit, do folks think that
the following is a reasonable requirement?

Proposed Requirement:
    Security solutions should provide mechanisms that allow processing
    to be off-loaded from routers to other assets when doing so would
    noticeably increase, e.g., the convergence time.  Deployment of
    off-loading must be implemented in a way that can maintain the
    integrity of the results of the processing, not introduce any
    single points of failure, and not contain vulnerabilities that
    introduce an unacceptable level of risk.

This raises the question of time scales.  What requirements would be
appropriate concerning "timeliness"?  For example, when an organization
receives a new IP address prefix, how long should they expect to have
to wait before the information has propagated to the furthest corners
of the Internet?

Should there be something like an 80/20 guideline where 80 % of the
Internet should see the new prefix by time T but the other 20 % may
take longer?

Note that both s0BGP and S-BGP use out-of-band data registries /
repositories to hold origin information.  As the interval T
decreases, the data has to be propagated faster.  At some T the use of
out-of-band information stores would cease to be viable and in-band
mechanisms would be required (which may preclude the ability to
off-load processing and crypto from the routers).

Should the working group try to set guidelines so that customer can
have reasonable expectations of how long things will take?

Other situations include a customer who switches providers: how long
should it take for the rest of the Internet to learn of the change?
Does the answer depend on whether the customer has his own prefix or
is/was using a prefix from the soon to be former provider?  What about
when a customer decides to become multi-homed?  Should there be a
guideline for how long it will take to propagate that information?
Does the answer depend on the prefix?

> This way the routers don't need to do any crypto.

I think "any" is too strong a term, at least if one does not consider
clear-text passwords to be adequate to protect access to a router.
Do folks think that the following should be a requirement?

Proposed Requirement:
    There needs to be a mechanism that uses "strong" authentication to
    verify the authenticity of management access to a router, and that
    can assure the integrity of management commands or data communicated
    between a router and its authorized managers.

<SNIP>

> I don't doubt Randy's remark that there have been some, but the fact
> that the victims don't want to talk about it makes me assume the
> attacks could probably have stopped using today's technology.

A different perspective is that a public acknowledgement that an ISP
has been successfully attacked might cause sufficient concern in the
customer base that would push an ISP struggling to survive over the
edge.

Maybe consumers need to be educated to the fact that attacks happen,
and they are, if we do a good job, no big deal.  Banks are robbed,
there is credit card fraud, neither seem to drive folks away from the
use of banks or credit cards.  We need to get to the point where
attacks on the internet do not even make the news.

> However, just because there is problem A doesn't mean you shouldn't
> do anything about problem B. It's not like work on routing security
> will take away time from installing anti-spoofing filters.

True for the case you point out, but it may not be true for all A and B.

> 192.168.0.0/16 to inform me of this fact.

Are there requirements that the working group should make concerning
organizations that want to intercommunicate across the public Internet
using those addresses?  What mechanisms are used today, VPNs?  If so,
should there be any requirements about mechanisms to prevent the
leaking of addresses from one of a customer's VPNs into their other VPNs?
Are simple route filters the answer?  What about when the filters are
mis-configured?  Maybe that is "their problem" and not the ISP/pubic
internet's problem.  Would that be consistent with customer expectations?

> interfaces.

Should we enumerate and document the factors that lead to the
conclusion that it can't be done?  E.g., things that were infeasible a
year ago might no longer be so next year.  Is it "simply" an issue of
memory or processing power?  Is it an issue that any prefix might be
received on any transit interface (even if that prefix has not been
advertised to a peer via that interface -- as might be the case if ISP
A does not want to provide transit service for ISPs B and C that peer
directly)?  Is it because it is hard to specify/manage a filter for
the small set of prefixes to be excluded since doing so requires
enumeration of the very large complement set of acceptable prefixes?
Is it an issue that the current mechanisms used to implement user
traffic filtering cannot keep up with the line rates?  Is it a return
on investment argument that the possible errors caught are so few that
the cost of catching them is not worth it?

> > If one coordinates attacks designed to effect DoS on central servers
> > for route checking with injection of bad routes, then we have a
> > recipe for a successful attack.
> 
> I think if there is a successful DoS attack on central infrastructure,

Should there be a requirement that routing must continue to "work"
when access to "central infrastructure" is not available?  If so, for
how long - 5 minutes, and hour, half a day, a few days?  Should any
effects of denied access be limited to "future changes" to peerings or
new prefixes being allocated, i.e., anything that was able to be
routed before the attack should continue to be routed after it?

> then a few bad routes are the least of your concerns.

Wouldn't the "damage" be more a function of which (customer's) routes
were adversely impacted, than a function of the number of impacted routes?

> Also, these boxes don't have to talk to the rest of the world so
> they can easily be protected against flooding attacks.

What requirements are necessary to implement such a mechanism?  It
seems like all the routers in the AS would need to be able to
reach/route to the boxes.  One might not advertise the prefixes used
by the boxes outside the AS and/or place ingress filters on the data
traffic to block outside access to the boxes.  But couldn't one
implement an IP-in-IP attack where the outer header reaches into an AS
and the inner header goes to the box(es)?  Are requirements needed
about which routers may or may not perform decapsulation?

> I would like to see external routing policy boxes anyway, regardless
> of new BGP security mechanisms, since it allows easier and better
> management.

I've heard different answers about whether ISPs must/should/may
"register" their routing policy.  Is there now consensus on an answer?
Maybe there are different flavors of policy -- some policy that
everyone agrees must be registered and some policy that may not.
Has anyone tried to break down the different types of policy and
to categorize the information?

If the answer were "must register", and some organization(s) declined
to do so, should there be a requirement that failure to register not
impact the ability of any other organization to route their customers'
traffic, and any weaknesses/damages be limited to the customers of the
ISP that chose not to register their policy?

Are the security requirements the working group produces to be limited
to an Internet that has essentially static inter-AS peerings (as I
think is the case for today's ISPs), or should there be a requirement
to support a more dynamic topology where whole networks move their
attachment point from one ISP to another?

<SNIP>

> Remember that not everything is implemented in the way that would be
> most beneficial, for a variety of reasons.

Should there be a requirement that A's bad implementation (of either
software or "policy" or whatever) not result in increased risk for B?

Charlie

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Nov 2002 12:59:15 +0100 (CET)

> events at the beginning of an ISP's learning curve, or an ongoing

I think it will remain fairly constant as more and more people implement
it and start climbing up that learning curve. Also, it never goes away
completely: all this secret stuff is hard to manage so it will go wrong
a few percent of the time.

>     the live Internet without impacting any router's Decision Process.

Agree.

>     should be rejected if a security mechanisms detect a problem.

How about this, in addition to what you're suggesting:

	An implementation must provide a way for the user to select
	different actions for when routing information can't be
	validated, but the failure appears to be in the validation
	mechanisms and the risk level is low (for instance, the routing
	information is the same as existing routing information) and for
	when the failure either doesn't appear to be in the validation
	mechisms and/or the risk level is higher.

> some TBD date in the future)?

Routing registries will get better, but it is very dangerous to depend
on them, as there are only a few and they do not have the built in
redundancy features such as (for instance) the DNS root servers.
Example: last week there was a power outage in Amsterdam, which took out
RIPE. Now this will get better (generators were already scheduled for
delivery it seems) but the risk won't go away completely.

The large ISPs are in a good position to sign the certificates for their
customers. They can also cross-sign. Then you only need a few
certificates for the largest ISPs in your router. This and the IRR data
could be complementary: a customer would have two chances to get it
right rather than one.

> whatever solutions are eventually adopted :-).

Sure, a bad solution can make it worse... If you implement this and it
allows _everything_ even though we know many people don't register their
stuff properly today, then obviously the security checks aren't very
strict.  :-)

If it allows less than anything you break connectivity.

>     is to be considered authentic.

Yes. But we should explicitly list that a solution may need to be
configured with 100,000+ individual prefixes that are allowed without
protection. In other words: a 100k+ access list.

> Only used if no other tamper-free route is available?

1. Raise an alarm
2. Behavior (use/don't use/only if nothing else) should be configurable

>     noticeably increase, e.g., the convergence time.

No. The convergence time is a cost tradeoff: throwing hardware at it
makes any solution fast, but ultimately it should be the user who
decides whether she wants to buy some 25k RSA per second cards for a
router or do this on a cluster of quad 2 GHz P3s.

>     Deployment of

Seems a bit general to me, but sure, this is what we want.

> to wait before the information has propagated to the furthest corners

It may take several minutes (30/40 seconds per AS) today under worst
case conditions. I'd say anything that takes more than 5 seconds per AS
by design is no good. (Sure, in practice it could be more.)

> off-load processing and crypto from the routers).

There are two problems:

1. A new prefix is announced, with completely new
   authentication/authorization data. This may take a few minutes, or
   even 24 hours if depending on a registry (preferably faster, though).

2. A previously know prefix is reannounced. This must be fast (not
   significantly slower than today).

> have reasonable expectations of how long things will take?

It would be good if everyone could agree on reasonable guidelines, yes.
That should save everyone disagreements later on.

> should it take for the rest of the Internet to learn of the change?

See case 1. above.

> clear-text passwords to be adequate to protect access to a router.

Ok, "per routing update".

>     between a router and its authorized managers.

I think most routers already support SSH and SNMPv3, but it never hurts
to say this is a good thing, of course...

> customer base that would push an ISP struggling to survive over the

Then Randy could have said "I know of a ... attack but I'm not telling
you on which network".

> using those addresses?

???

> year ago might no longer be so next year.

Well, let me rephrase: you can do anti-spoofing filtering on a transit
connection, but it won't help you much as by definition a transit
connection will deliver packets from the entire internet, so all
possible source addresses should be accepted over a transit link. In
other words: you can have a list of all people that are allowed to enter
the bank vault, but you can't make a list of all people who are allowed
to enter the front door of the bank as it is open to the public.

> when access to "central infrastructure" is not available?

Note, this is central to an AS, not central to the whole network.

> If so, for how long - 5 minutes, and hour, half a day, a few days?

Yes, it should continue to work. How long? Simple: as long as possible.

> Should any

Yes, that sounds reasonable.

> were adversely impacted, than a function of the number of impacted routes?

I don't understand.

> reach/route to the boxes.

All the routers served by that box, yes.

>  One might not advertise the prefixes used
> traffic to block outside access to the boxes.

Yes, or use RFC 1918 space.

> But couldn't one

Can we trust people to implement something reasonable here?

Iljitsch

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Nov 2002 10:06:30 -0500

>filter their customers is the short road to disappointment.

Amsterdam must be a more civilized place than most major U.S. cities :-)

Most apartment complexes here do not have doormen. The "undesirable 
elements" can and do gain entrance by "buzzing" apartments randomly 
in hopes someone will let them in, or by following in legitimate 
residents (tailgating), showing up dressed as a delivery person, etc. 
So, we have adopted a more defensive posture and assume the need to 
secure entrance to individual apartments as the responsibility of the 
residents.

Steve

---

From: Tony Tauber <[email-masked]>
Date: Mon, 11 Nov 2002 10:55:06 -0500 (EST)

On Sun, 10 Nov 2002, Charles Lynn wrote:

> Folks,
>
> I think that Iljitsch's response to Joel and his observations
> suggest possible requirements for any security solutions that the
> group may generate.  Here are some candidates, interspersed with
> recent motivating remarks.  What other requirements would folks like
> to propose?

Charlie,

Thanks for trying to start to mold this freewheeling discussion into
something more focused.  We should always be thinking, IMO, of how
the conversations on this list relate to the mission of this WG.

I think things should be kept relatively quite generic.
Perhaps we could characterize what you've proposed below as
"Operational Requirements for Inter-domain Security Mechanisms?"
I think BGP or any proposed modifications to it should not be
specifically mentioned in such requirements (or else we'd be talking
about solutions); and indeed that's what you've achieved nicely below.

Provoking people to think about timescales that are acceptable or
unacceptable is useful also.

On the last point below about crypto and authentication for management
functions, I think that part is out of scope for functions of routing
protocols.

This reshaping is quite promising and perhaps could become the seed
for a brief draft which could inform the proposed BGP enhancements or
any subsequent work in the Inter-domain arena.

Tony

>     Any solution must allow for the co-existence of both protected
>     and non-protected information, and the authoritative source of
>     the information must be able to control whether or not the
>     information is to be considered authentic.
>
> Proposed Requirement:

---

From: Steve Suehring <[email-masked]>
Date: Mon, 11 Nov 2002 22:39:39 -0600

Comments inline.

> events at the beginning of an ISP's learning curve, or an ongoing

I believe that the problems would mostly be encountered at the beginning.  
Once learned, mistakes usually don't happen twice.  Usually.

>     the live Internet without impacting any router's Decision Process.

I can see the benefit of this but it may be difficult for ISP's to really 
do this, so maybe it should read as "There SHOULD be a way for an 
ISP..."(?)

>     should be rejected if a security mechanisms detect a problem.

I would propose that flexibility be built into this so a policy can be 
utilized to enable the ISP to determine the action based on the source 
and/or security violation.

The new proposed requirement would be something like:

===
Proposed Requirement:
  Networks [ed. note:  maybe "AS" instead of "Networks"?] participating
  in routing exchanges must produce a routing  protocol security policy
  to determine what action, if any, will be taken when a security 
  violation occurs.  The policy may contain items such as source, 
  violation, and resulting action to take.  Further, there must be 
  an automated mechanism to enforce the routing protocol security 
  policy and can take action according to the policy.
===

Now, with that all typed out, I'm not so sure that it's feasible in the 
real world.

>     introduce an unacceptable level of risk.

In general I tend to agree with this, I'm a believer that routers should 
route things.  However, I'm trying to come up with a practical solution to 
implement the proposed requirement.  I'm only coming up with one in my 
mind so far, but need to think about it some more before I make a 
complete fool of myself.  Anyone else?

> ISP that chose not to register their policy?

From a non-technical standpoint, what would be the consequences of a "must
register" scenario if an organization refuses to register their policy and
suddenly their customers are blackholed?  Litigation?  Against whom?  
From a security standpoint, would the process of registration possibly
release more information than it should to unauthorized individuals?

Steve