Subject: Re: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03

From: [email-masked]
Date: Thu, 19 Jan 2006 11:14:45 -0500 (EST)

I would like to speak against including hardware and software limitations
as bgp security requirements.

I believe that these are very important issues.  I just don't think that
they constitute security requirements.  They could be called
deployment considerations, or solution requirements, or some such.

I believe that security requirements should not vary over time, absent
such events as the discovery of brand new attacks no one had ever
thought of before.

But we know that issues of hardware and software performance and cost
will necessarily vary in importance over time and over networks.
They will vary because:
   hardware performance, even averaged over the entire router base, 
      will vary over time
   software performance will vary, both as improved algorithms become
      available and as hardware changes occur
   network and protocol design/engineering can ameliorate demands on 
      under powered routers
   the definition of "heavy" will vary by the network
   tolerance to risk and to cost vary by network

It would be best if the bgp security requirements did not prevent
consideration of a solution that would be acceptable to some portions
of the Internet or to specific networks, either now or N years from now.

So I'd say these issues should be a separate section of the document
that talks about considerations of deployment, or barriers to
deployment (though that latter might be "unnecessarily pejorative" as
someone I know likes to say).

Note also: the suggested new text as stated says that heavy processing
must not be required of "all routers".  But since there is already a
requirement addressing tolerance of incremental deployment, there's
already a requirement that not all routers participate.  So the text
as stated is obviated by other text.  If you really did mean the "all"
part of "must not require that heavy processing is required on all the
BGP routers", then we don't need this requirement.

--Sandy

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

---

From: Russ White <[email-masked]>
Date: Thu, 19 Jan 2006 13:31:26 -0500

> someone I know likes to say).

The main problem here is that you end up considering them "second class 
citizens." In other words, you end up saying that securing "BGP 
processing" is somehow more valid than ralizing the impact securing that 
processing might have. Of course, a lot of this comes down to whether 
you believe that security is primarily focused on making existing 
specifications "secure," or about securing systems, with the inherent 
tradeoffs that entails. You secure networks, not specifications, in the 
real world, something we should probably keep in mind. :-)

Anyway, IMHO, if we move this stuff all to a seperate section, we need 
to make certain it's clear in the document that this doesn't make them 
secondary concerns, or secondary issues, that aren't as important as the 
"primary issue" of "making the BGP specification secure."

> of the Internet or to specific networks, either now or N years from now.

Would you say it shouldn't favor solutions that can be deployed today, 
however?

> BGP routers", then we don't need this requirement.

These are not orthogonal, they are complimentary. You don't get rid of 
red because you have blue, you mix the two to make purple.

:-)

Russ

- -- 
[email-masked] CCIE <>< Grace Alone