Subject: Re: [RPSEC] Potential requirements

From: [email-masked]
Date: Mon, 11 Nov 2002 11:08:47 -0500 (EST)

>> 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.
>
>Agree.

Strongly disagree.

This is the Routing *PROTOCOL* Security Requirements working group,
not the Routing *SYSTEM* Security Requriements working group.

Writing a site security handbook especially for ISP's might be a good
idea but not the task of this group.

It's difficult to separate considerations of routing protocols (e.g., BGP)
from considerations of operating by using routing protocols (e.g., ISPs)
because so often the two are coincident.

But the issues involved differ and the protections possible differ.

If we want to take on ISPs' security, we'll need a much longer time line.

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Nov 2002 18:34:58 +0100 (CET)

> idea but not the task of this group.

I don't think this falls outside the scope of routing security
requirements, although it comes close and you are right that we
shouldn't require things that are out of scope for what we're doing
here.

Maybe it's a bit obvious, but IMO it is a valid requirement to be able
to test this first in a lab and then on real infrastructure, but without
impacting the way packets flow just yet. I would like to generalize the
latter into the following:

	It must be possible for the processing of new security
	mechanisms in existing protocols to be disabled and reenabled
	without disrupting any routing protocol state. In the disabled
	state, the implementation must continue to accept and possibly
	relay security information as required by the protocol
	additions, but it should otherwise act as if unaware of this
	information.

and

	It must be possible for any routing protocol security mechanisms
	to be used in a "warning-only" mode, where the security
	information is processed, but it is ignored in the route
	selection process. The instances where application of the
	security information would lead to different routing decisions
	are logged.

Iljitsch

---

From: "Barry Raveendran Greene" <[email-masked]>
Date: Mon, 11 Nov 2002 09:45:50 -0800

Routing security that does not take one the systems approach is making
fundamental errors. If you want to make improvements in BGP's security, then
you HAVE TO UNDERSTAND WHAT YOU CAN DO WITH TODAY'S TOOLS! You also have to
understand why people do and do not used these tools. Not know those factors
will mean you go down a path of designing undeployable "routing protocol
security features."

One of the problems I'm seeing in this group is the division between the
people running routing protocols in an ISP's network and the people sitting
in the labs studying routing protocols. If you want the two worlds to reach
consensus, then efforts to make sure both side understands the other. If
that means documents to clue in both sides as a foundation document, then
yes, it would be within the charter.

> not the Routing *SYSTEM* Security Requirements working group.
>

---

From: Russ White <[email-masked]>
Date: Tue, 12 Nov 2002 10:53:40 -0500 (EST)

> This is the Routing *PROTOCOL* Security Requirements working
> group, not the Routing *SYSTEM* Security Requriements working
> group.

I think, perhaps, it might be good to try and define the
difference. For instance, does the routing system include:

-- The routing protocol?
-- Processes which implement that routing protocol running on
   specific devices?
-- The devices on which such processes execute?
-- The authority to originate routing information through such
   processes?
-- The validation that a given device actually is supposed
   to run such processes, and interact with other devices
   also running such processes it is connected to?
-- The interaction between two devices running such processes?

Before we say that we should or should not address a "routing
system," we need to define the term first. Is the authorization
and vlaidity of routing information a part of the protocol, or
the system? 

Can you, in fact, secure a protocol simply by securing the
communication between two devices running that protocol, and when
you move into areas of validity of membership, and authorization,
you are, by definition, moving into a "system," rather than a
"protocol?"

:-)

Russ

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Nov 2002 11:29:07 -0500

>you are, by definition, moving into a "system," rather than a

Protocols embody semantics and the security of the protocol must 
relate to those semantics. So, for example, a BGP UPDATE message is 
an assertion that the owner of a block of addresses authorized an AS 
to advertise that block, and that each AS along the path authorized 
the next AS to advertise the block. A security model for BGP, for 
example, needs to encompass these semantics. So, even if we talk in 
terms of securing routing protocols, vs. systems, there is more to 
the task than your concluding remarks above would suggest. Again, 
absent a threat model, we cannot make any reasonable decisions about 
what is or is out of scope even relative to the nominally restrictive 
notion of securing routing protocols.

Steve

---

From: Russ White <[email-masked]>
Date: Tue, 12 Nov 2002 11:51:38 -0500 (EST)

> Protocols embody semantics and the security of the protocol
> must relate to those semantics. So, for example, a BGP UPDATE
> message is an assertion that the owner of a block of
> addresses authorized an AS to advertise that block, and that
> each AS along the path authorized the next AS to advertise
> the block. A security model for BGP, for example, needs to
> encompass these semantics. So, even if we talk in terms of
> securing routing protocols, vs. systems, there is more to the
> task than your concluding remarks above would suggest. Again,
> absent a threat model, we cannot make any reasonable
> decisions about what is or is out of scope even relative to
> the nominally restrictive notion of securing routing
> protocols.

Well, most protocol designers and implementors would disagree on
this point--a protocol is simply a set of signals for sending
information, and knowing how to parse it intelligently. Protocols
do not, in any way, imply the correctness of what is sent. IPsec
cannot validate the contents of what is sent, only that it is
sent without medling, prying eyes seeing it, etc.

This is a very common distinction in the routing world.... Coders
implement protocols in the sense of building the processes which
follow the fsm described in a protocol spec. However, coders
don't often (necessarily) know how those protocols are used in
the real world, how they are deployed. For this, we rely on
deployers, which is an entirely different class of engineer. It's
not that one knows more than the other, etc, but their knowledge
realms are different.

I see the same divide here. Being able to make certain the
symantics of the protocol are properly followed is not the same
as making certain the information carried in the correct symatics
is also correct.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Nov 2002 12:45:14 -0500

>sent without medling, prying eyes seeing it, etc.

A protocol is not just the format of what is sent on the wire, 
although that is a common misperception. It also entails the state 
machine that each peer executes to determine what to do with the 
messages. I think we agree on that. Protocols at higher layers tend 
to have richer semantics and the processing embodies these semantics. 
For example, XML tags data in a fashion that maps the data to higher 
level meaning, as opposed to simple HTML tags that deal with data 
types but cannot tell a phone number from a credit card number. BGP 
is a routing protocol and the algorithm a BGP router uses to select a 
route from among the paths it receives from peers is based on the 
semantics I described in my previous message. Thus, to secure BGP, 
one must be cognizant of these semantics, and to the extent that the 
security features do this, the offered security will be better.

One can and should provide point-to-point communication security for 
BGP traffic using the MD5 crypto checksum hack or using IPsec, and at 
layer 3 or layer 4, where the semantics are simple, these security 
measures are appropriate. But a layer 3/4 security mechanism does 
address the wide range of security problems we face for BGP, and thus 
securing that protocol means securing the application in an 
application-specific fashion. So, your comments re IPsec are correct, 
but that is OK because the semantics for IPsec match that of the 
protocol layer at which it operates, and that layer is application 
independent.

Also, as someone who has designed protocols for a rather long time, I 
guess I question your opening assertion as well :-)

>not that one knows more than the other, etc, but their knowledge

We disagree again. Your comments might be true for a lower layer 
protocol, but for application protocols an understand of the context 
of use is essential to good protocol design. yes, there is a point at 
which people responsible for deployment take on responsibility for 
configuration and operation of the protocol implementations, but they 
cannot change protocols, only manage them via the controls provided 
by the protocol implementers and designers.

>as making certain the information carried in the correct symatics

An implementation of a protocol cannot operate "correctly" if the 
data delivered as inputs is in error. And when errors go beyond 
simple transmission errors or FSM errors, a higher level of error 
detection and rejection, a semantic-based error control mechanism, is 
needed. In routing, our ultimate security goal is correct operation, 
since incorrect or degraded operation is obviously not desirable and 
can lead to a variety of security problems. I don't see how one can 
aspire to correct operation of a routing protocol ignorant of the 
semantics that define correct operation.

Steve

---

From: Russ White <[email-masked]>
Date: Tue, 12 Nov 2002 13:13:19 -0500 (EST)

So, you are stating that the authorization to advertise a
specific prefix is part of the BGP protocol itself? Or the actual
path being "correct" from a policy perspective is a part of the
BGP protocol itself?

Okay, so let's say that BGP is a policy propogation mechanism, so
you _could_ stretch it in this case. But can you stretch it in
the case of OSPF, IS-IS, PIM, etc? In other words, as the same
question: Could the authorization to advertise a certain
destination as reachable through this device be a part of the
OSPF protocol itself?

I don't see it that way; I see those things as a part of the
routing system. I do not see forwarding packets, not device
security, as part of the routing system, however. So, I think, in
the end, we agree on what we are talking about, but not on the
terms used to talk about that "thing" (although there may be
disagreement at the edges). 

Which is why I think we need to define exactly what we mean when
we say "routing system," and "routing protocol." We have become
very focused on BGP, which isn't a "real" routing protocol, and
thus blurs the lines we are talking about. When we look at
different protocols (RIP, may we never have to worry about
security for RIP, though), we get a different picture, and one
that we still need to take into account.

:-)

Russ

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 12 Nov 2002 19:22:28 +0100 (CET)

On Tue, 12 Nov 2002, Stephen Kent wrote:

> BGP is a routing protocol and the algorithm a BGP router uses to select a
> semantics I described in my previous message.

From RFC 1771:

   For each newly received or replacement feasible route, the local BGP
   speaker shall determine a degree of preference. If the route is
   learned from a BGP speaker in the local autonomous system, either the
   value of the LOCAL_PREF attribute shall be taken as the degree of
   preference, or the local system shall compute the degree of
   preference of the route based on preconfigured policy information. If
   the route is learned from a BGP speaker in a neighboring autonomous
   system, then the degree of preference shall be computed based on
   preconfigured policy information.  The exact nature of this policy
   information and the computation involved is a local matter.

Current BGP implementations use the AS path length to select routes, but
this is something implementors came up with, and not an inherent quality
of BGP. The reason the AS path exists is to detect loops.

> Thus, to secure BGP,

It appears we have to look at implementations too. There wouldn't be
much reason to protect the AS path if it were only used for loop
detection.

Iljitsch

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Nov 2002 13:49:11 -0500

>path being "correct" from a policy perspective is a part of the

I am stating that BGP correct operation is based on an implicit 
assumption that the origin AS is authorized to advertise the address 
block by the owner, etc. Do you disagree?

>destination as reachable through this device be a part of the

I was using BGP as a specific example, one that I have studied for 
some time. I defer to Sandy or someone else who has studied OSPF to 
suggest analogous constraints for that protocol.

>disagreement at the edges).

Routing exists to tell routers where to forward packets, with the 
intent that the packets be delivered to the intended destination, 
subject to various other constraints we impose on routes. Because of 
the major role played by local policies in BGP, there are significant 
limits on the extent to which we can ensure that all of the inputs 
that we use in a local route computation are valid. But to the extent 
that we can validate those inputs, we eliminate means by which 
attackers can adversely influence the computation and disrupt 
routing. Attacks also can disrupt routing by causing routers to 
devote resources to processing bad packets, etc., and so not all the 
safeguards we need will be defined just through the protocols.  A 
system security approach is needed. But, within the definition of a 
routing protocol, we should detect and reject bad data to avoid 
making bad routing decisions on the basis of detectably bad inputs.

>that we still need to take into account.

I don't mean to suggest that one size fits all routing protocols. The 
semantics differ and must be characterized individually for each 
protocol, to be ale to make usefully detailed statements about the 
security requirements for each protocol.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Nov 2002 13:52:14 -0500

>of BGP. The reason the AS path exists is to detect loops.

I think it is a stretch to say that AS path length is usually used as 
a primary factor to select routes. Many routing algorithms have, 
historically, used path length or hop count as primary factor.

Steve

---

From: Tony Tauber <[email-masked]>
Date: Tue, 12 Nov 2002 14:04:50 -0500 (EST)

> I think we need to define exactly what we mean when
> we say "routing system," and "routing protocol."

To put a pragmatic spin back on things, I think we have to focus on
where the threats come whichever it is.

The threats are things like subverting or interrupting the flow of
traffic so consider the vulnerabilities which give rise to these.

$0.25

Tony

---

From: Russ White <[email-masked]>
Date: Tue, 12 Nov 2002 20:22:06 -0500 (EST)

> I am stating that BGP correct operation is based on an
> implicit assumption that the origin AS is authorized to
> advertise the address block by the owner, etc. Do you
> disagree?

Yes. :-)

If my daughter walks into a store with my credit card and
attempts to buy something, does her physical access to my credit
card mean that she is authorized to use it? No. Does a router's
apparent physical access to a given destination mean it is
authorized to advertise that destination? No.

Today, there are two parts to the way a routing protocol process
on a specific device determines it may advertise a particular
destination as reachable through this device:

-- The destination is configured to be directly connected, or
through a manually configured route statement claiming the route
is reachable "this way."

-- The routing protocol is configured to advertise said
destination.

Thus, today, we assume that the operator provides the
authorization for the routing protocol to advertise a particular
destination from a particular device. If you cannot, or do not,
make the assumption that manual configuration constitutes
authorization (which is why we have threats drafts, etc.), then
you must build some authorization into the system.

Advertisement of reachability is not tatamount to authorization
to advertise that reachability.

> I don't mean to suggest that one size fits all routing
> protocols. The semantics differ and must be characterized
> individually for each protocol, to be ale to make usefully
> detailed statements about the security requirements for each
> protocol.

Right.... Again, I think we are talking about the same thing,
just using different words. I think that the authorization to
advertise a destination is not part of the routing protocol, but
part of the routing system. I do not include access to the
physical device to be in the routing system; the configuration
which authorizes that device to advertise a given destination is
a part of the routing system, but not part of the routing
protocol.

I think you're saying that the manual configuration which
(today) constitutes the authorization to advertise a given
reachable destination is part of the routing protocol.

Is that correct?

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Tue, 12 Nov 2002 21:19:37 -0500 (EST)

> addresses authorized an AS to advertise that block,

And my point is that checking this assertion should be both a
part of any threat model(s), and a part of any requirements
document(s) that we put forth. Otherwise, you've not secured the
routing information, no matter whether you classify it as a
system or a protocol.

:-)

Russ

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 13 Nov 2002 10:01:33 -0500

> we say "routing system," and "routing protocol."

It occurs to me that we might be running into a definition issue with
the word "protocol" that I've seen before.

People who implement routing protocols usually think PDUs and FSMs.

Crypto people tend to think of the flow of information through a
system.  (If I had my copy of Applied Cryptography, I'd paste Bruce S.'s
definition.)

Keeping the different contexts in mind might help us see eye to eye a
bit easier.

-- 
Jeff Haas 
NextHop Technologies

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Nov 2002 11:32:44 -0500

>to advertise that reachability.

You seem to be making a distinction between authorization via local 
assertion vs. authorization via a more formal structure. We know that 
the former is prone to error, and vulnerable to attack. So, I think 
we need to abandon the notion of implicit authorization via local 
assertion.

Using your phrase from above, I would say that advertisement of 
reachability SHOULD be equivalent to authorization to advertise hat 
reachability and that BGP assumes this is the case in making routing 
decisions. To argue otherwise is to say that it is a good thing to 
make routing decisions based on unauthentic data, which is ludicrous.

>a part of the routing system, but not part of the routing

We disagree, because the protocol has as it (unstated?) goal the 
propagation of accurate reachability data to AS's. Nobody would 
suggest that all the effort that went into the design of BGP and the 
execution of BGP is warranted if propagation of bogus reachability 
data were the intent :-)

>reachable destination is part of the routing protocol.

No. I think that my comments above clarify the distinction between a 
local assertion about authorization to advertise vs. an independent 
verification of that assertion.

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 13 Nov 2002 18:09:40 +0100 (CET)

> we need to abandon the notion of implicit authorization via local

On the other hand, "more formal structures" tend to be very complex to
operate and manage and lead to a significant number of false positives
(to the extend that rejecting valid information can be called
"positive").

I don't think we can dismiss either option out of hand.

> reachability

Who gets to issue this authorization? The internet is a decentralized
network. This is an important property.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Nov 2002 12:41:13 -0500

>(to the extend that rejecting valid information can be called

The formal structures exist for the data in question, and there in 
agreement that the allocation  of addresses and AS numbers must be a 
coordinated process using these sorts of structures.  (I'm not 
talking about routing registries, but the RIS here.) This makes them 
different from contexts in which people need to create such 
structures from scratch.

On what basis do you assert that the RIR data would lead to 
"significant numbers of false positives?" Yes, the legacy allocations 
for address blocks is not in great shape, but that is a problem that 
is already being worked.

>network. This is an important property.

As noted above, the RIRs are authoritative sources for who owns what 
AS numbers and what address blocks. In the case of S-BGP, we include 
provisions for owners of address blocks to attest to the 
sub-allocation of address blocks, consistent with the way such 
sub-allocations are managed. So, the tree structure that represents 
address allocation is captured by a PKI that parallels that 
structure, and that represents the authorization data one needs to 
verify advertised routes.

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 13 Nov 2002 19:22:17 +0100 (CET)

> talking about routing registries, but the RIS here.)

RIS?

> This makes them

> for address blocks is not in great shape, but that is a problem that

Very simple: very many people don't register their stuff, or don't do it
well. I'll take the time to evaluate a sample after Atlanta.

> AS numbers and what address blocks.

Nobody "owns" address blocks. And the actual involvement of the RIRs
themselves is very limited: most of what's in their databases is put
there by ISPs. The very same people that as a group don't bother with
the BGP MD5 option.

> In the case of S-BGP, we include

Even if we can make a successful transition from what we have now to
what S-BGP requires, I'm still very uncomfortable with having just a
hand full of entities at the top level of the tree.

To quote Bassam Halabi in "Internet Routing Architectures" (use the
first edition, the quote is watered down in the second) (from memory):
"People are surprised when networks fail. I'm surprised when they
don't."

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Nov 2002 13:49:00 -0500

>>  talking about routing registries, but the RIS here.)

Sorry, RIR (Regional Internet Registry, e.g., ARIN, RIPE, APNIC)

>well. I'll take the time to evaluate a sample after Atlanta.

You don't get an allocation of address space from an RIR without 
being registered. if you get your block from an ISP and run BGP and 
want to run S-BGP, then the ISP would have to issue a cert to you to 
represent that sub-allocation, a local operation not involving the 
RIR.

>there by ISPs. The very same people that as a group don't bother with

You are confusing different levels of allocation.  Rather than 
bothering the list with a tutorial on this, I suggest you look at the 
S-BGP papers at the URL I sent earlier, and then contact me privately 
if you have questions.

>"People are surprised when networks fail. I'm surprised when they

The people at the top of the address allocation tree have been there 
since 1996. They are not going away. The S-BGP architecture does not 
require interacting with them any more frequently than ISPs and 
multi-homed subscribers do today, and it does not rely on them to 
provide a high-availability service. Their role is the same as it is 
today, with the exception that they act as CAs to provide certs 
attesting to address allocation and AS ownership, so that these certs 
can be used in a distributed algorithm to verify assertions made by 
ISPs re paths.

Steve