Subject: Re: [RPSEC] BGP Requirements Draft

From: Sandy Murphy <[email-masked]>
Date: Mon, 26 Sep 2005 10:08:32 -0400 (EDT)

>the AS's listed in the AS Path must be connected, not through
>some third party not appearing in the AS Path, but directly, as shown in
>the AS Path, in the order shown in the AS Path.

But the AS's listed, even though they meet this test, don't have to
have touched the AS_PATH.  They might never have seen the route.

The reason checking for your AS in the AS_PATH was a way to check for
a loop was that the AS_PATH was supposed to list all the AS's that
had seen/touched/propagated/announced the AS_PATH.  So if your AS wasn't
on the AS_PATH, well, there wasn't a loop through you.

But if the AS_PATH doesn't necessarily list all the AS's that
have seen/touched/propagated/announced the AS_PATH, then you can't
be sure, even if you check for your AS, there might be a loop
anyway.

--Sandy

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

---

From: Paul Jakma <[email-masked]>
Date: Mon, 26 Sep 2005 15:35:00 +0100 (IST)

On Mon, 26 Sep 2005, Sandy Murphy wrote:

> had seen/touched/propagated/announced the AS_PATH.  So if your AS 
> wasn't on the AS_PATH, well, there wasn't a loop through you.

This isn't security related though.

Even with BGP secured, you still have to trust that ASes you forward 
to/from have described their state to you or others correctly. An AS 
could describe paths to you which from a security POV (regardless of 
the proposal) check out 100%, but through miscreance or bungling 
don't go where you think they go (eg loops, whatever).

In which case, what exactly does in-line AS_PATH signing achieve that 
out-of-band can not?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"Right now I'm having amnesia and deja vu at the same time."
 		-- Steven Wright

---

From: Russ White <[email-masked]>
Date: Mon, 26 Sep 2005 10:39:50 -0400

> be sure, even if you check for your AS, there might be a loop

????

You must be talking about a forwarding loop, not a routing loop. Since 
the forwarding path is out of scope, I don't see how this applies.

:-)

Russ

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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Sep 2005 11:49:34 -0400

Paul,

We're trying to define requirements for BGP security in this 
document, and trying to avoid specific solution discussions. From a 
security perspective it is always preferable to define requirements 
in terms of what constitutes correct or secure operation, instead of 
trying to identify all the classes of attacks that might cause a 
systems to deviate from secure/correct operation.

My argument is that the BGP RFC defines the AS path info as 
reflecting the path traversed by UPDATEs that yield the UPDATE in 
question. Thus, correct operation is defined on this basis and we 
ought to specify requirements that are consistent with this 
definition. Arguments about path validation ought not be cast in 
terms of specific mechanisms for achieving this, e.g., digital 
signatures applied to AS path info, but rather the functional goal as 
expressed in the BGP spec.

Another thing to note is that the best we can hope for re BGP 
security (an application of the principle of least privilege) is to 
provide ASes with data that they can use use to decide whether to 
accept a route or not, based on the authenticity of the info 
expressed in a received UPDATE. We can't make anyone do anything. But 
we can allow an AS to have better info about the authenticity of an 
UPDATE it receives.

If we provide security mechanisms that allow an AS to determine if 
the route expressed in an UPDATE meets the simple criteria 
established in the BGP spec, that constitutes one form  of 
authenticity check, though not a perfect one. (For example, BGP does 
not provide a good way to deal with timeliness of route withdrawals, 
without adding timestamps to UPDATEs and imposing a requirement to 
re-advertise a route periodically.)

Security mechanisms that allow an AS to determine only if a route 
might be advertised legitimately (as opposed to whether it was 
advertised), allow for a range of attacks, e.g., ones that cause 
traffic to flow over backup paths when such paths are not supposed to 
be exercised. This is obviously a less secure situation.

Steve

---

From: Paul Jakma <[email-masked]>
Date: Mon, 26 Sep 2005 18:03:44 +0100 (IST)

On Mon, 26 Sep 2005, Stephen Kent wrote:

> document, and trying to avoid specific solution discussions.

Yes indeed. Apologies :).

> From a security perspective it is always preferable to define 
> requirements in terms of what constitutes correct or secure 
> operation, instead of trying to identify all the classes of attacks 
> that might cause a systems to deviate from secure/correct 
> operation.

Indeed. Though, this rather lively discussion started because some 
proposed requirement is seen as either being:

- too 'tight' and hence likely to preclude one possible solution.

- too loose

If something is to be a requirement, rather than a goal, it does need 
to have some kind of eye to the possible solutions.

> signatures applied to AS path info, but rather the functional goal 
> as expressed in the BGP spec.

Well, this is a tricky question. I think though that BGP is a bit of 
an ostrich-feather strip-tease act of a protocol - it quite 
deliberately leaves a lot to the imagination^W^Woperational 
interpretation. I'm not sure one should try apply the strictest of 
readings (at least not the base spec..).

> expressed in a received UPDATE. We can't make anyone do anything. 
> But we can allow an AS to have better info about the authenticity 
> of an UPDATE it receives.
>
> authenticity check, though not a perfect one. (For example, BGP 
> does not provide a good way to deal with timeliness of route 
> withdrawals, without adding timestamps to UPDATEs and imposing a 
> requirement to re-advertise a route periodically.)

Ok, there's the nub of the problem. If authenticity implies per-hop 
signing of AS_PATH, then clearly that's not going to work as a 
/requirement/ given at least one possible solution explicitely does 
not have that as a goal. (At least, it can't be adopted as a 
requirement without first going into a discussion of the solutions - 
as has happened in this thread inevitably).

So clearly we need to either:

- find a more general wording

OR

- discuss the solution and figure out whether that solution should be 
discounted (so this requirement can be adopted) or whether this 
requirement must be dropped/changed.

I think Russ's suggestion that the wording in 1.3 regarding 
'deemed "valid"' criteria be:

  "as the BGP spec states it /should/ have"

(which wording is the sticking point here (right?)) is a reasonable 
compromise, at least for a Requirements document that is to leave 
open the door to the various suggested approaches to securing BGP...

A requirement for SHOULD have doesn't preclude a solution that 
guarantees it /MUST/ have.

> traffic to flow over backup paths when such paths are not supposed 
> to be exercised. This is obviously a less secure situation.

But that would be something like a case where:

A-B---C-n
    \ /
     D

Where B uses the path to C as its best-path, but advertises B-D-C to 
A. The AS_PATH signing case does not prevent that either AFAICT.

-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
For a light heart lives long.
 		-- Shakespeare, "Love's Labour's Lost"

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Sep 2005 13:41:01 -0400

Paul,

There are various distinctions between what Russ suggests and what I 
and other's have suggested re how to formulate requirements.

Perhaps the biggest distinction is that, as I noted, it's preferable 
to develop requirements from  clear statements about base 
functionality than based on countermeasures to selected classes of 
attacks or based on notions of what is or is not feasible. Russ wants 
to adopt language that is inclusive of schemes that seek to 
accommodate policies that might be expressed by ASes, perhaps 
external to BGP, even if these policies cannot be expressed via BGP. 
I see this as outside the scope of a BGP security requirements 
document.

>>...

You are mixing a discussion of forwarding and with routing. We all 
agree that we cannot ensure that packets are forwarded via the 
advertised routes, although that is clearly the intent of the 
advertisements.

A more precise description of what I said, relative to the diagram 
above, is that C has its link to B as a primary path and via D as a 
backup. If we adopt a broad definition of what constitutes a 
legitimate advertisement, then even when the B-C link is up and C is 
advertising only that route, an advertisement that calls for traffic 
to flow via the B-D-C path would be accepted by A. in this trivial 
topology this distinction isn't really important, but if one makes 
the topology a bit more complex, and with longer paths, then you can 
see how such advertisements can trigger a significant deviation from 
correct operation.

Steve

---

From: Paul Jakma <[email-masked]>
Date: Mon, 26 Sep 2005 19:25:00 +0100 (IST)

On Mon, 26 Sep 2005, Stephen Kent wrote:

> Perhaps the biggest distinction is that, as I noted, it's 
> preferable to develop requirements from clear statements about base 
> attacks or based on notions of what is or is not feasible.

Right, but conversely, you're proposing a requirement which clearly 
some do not see as necessary. (I have to say, I'm not convinced it's 
worth the cost myself). The requirement must either side-step this 
disagreement in some way through its wording or recognise it needs to 
be investigated further and resolved.

> Russ wants to adopt language that is inclusive of schemes that seek 
> to accommodate policies that might be expressed by ASes, perhaps 
> external to BGP, even if these policies cannot be expressed via 
> BGP. I see this as outside the scope of a BGP security requirements 
> document.

Well, the prime distinctions and security/cost/benefit tradeoffs 
AIUThem are not to do with how rigorous an interpretation of BGP is 
acceptable, but with whether it is to be in-band with the UPDATEs or 
out-of-band.

Even if these AS_PATH TE practices did not exist, or were not really 
important (and they may not be), that's still not a reason to rule 
out the out-of-band approach at /this/ stage. Out-of-band versus 
in-band each have different costs which make examining /both/ 
approaches worth-while.

The current wording of the requirements seems to lean quite a bit 
toward in-band (indeed the proposed "as dictated by the BGP spec" is 
a side issue, its the existing wording of "has the update traveled 
the path" which is leading).

>> Where B uses the path to C as its best-path, but advertises B-D-C to A. The 
>> AS_PATH signing case does not prevent that either AFAICT.
>

> advertised routes, although that is clearly the intent of the 

Sorry, I must have been confused by the use of the word "flow". ;)

> legitimate advertisement, then even when the B-C link is up and C 
> is advertising only that route, an advertisement that calls for 
> traffic to flow via the B-D-C path would be accepted by A. in this 
> trivial topology this distinction isn't really important, but if 
> one makes the topology a bit more complex, and with longer paths, 
> then you can see how such advertisements can trigger a significant 
> deviation from correct operation.

It would be trivial to have the out-of-band approach allow C to 
indicate that only C->B is valid for a given NRLI. Details of this we 
can leave for later.

We /can/ obviously discuss this now, so as to establish that indeed 
the out-of-band approach can achieve the same abstract goals as 
in-band, or we can make the requirement be less detail-focussed so 
that we can defer this discussion.

Eg, drop the 'has the update traveled the path' criteria and instead 
just cut out that section altogether. We already have:

" o Does the AS_PATH, received via an UPDATE, represent a valid path
     through the network?"

And I think it would be best if we /don't/ try and define "valid" in 
the requirements, and leave that definition nicely vague.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
QOTD:
 	"I only touch base with reality on an as-needed basis!"

---

From: Stephen Kent <[email-masked]>
Date: Mon, 26 Sep 2005 15:26:03 -0400

Paul,

You're right that not everyone agrees with the need to verify routes 
as advertised vs. how they might be advertised. But, the reasons for 
the disagreement are rarely clearly articulated. Often there is an 
underlying current of "the only ways we know how to do X seem too 
expensive, so we can't make X a requirement." I appreciate the 
concern over the viability of proposed solutions, but a requirements 
document that is tailored to accommodate what some folks believe is 
possible at a given point in time runs the risk of being arbitrary 
and quickly outdated. Also, there are many folks who have expressed 
the view that a scheme that relies on all ISPs to publish their 
policies in enough detail to support the "it could be a legitimate 
route" model is a non-starter too. So we have expressions of groups 
of folks who

You are right that a very important distinction between the two 
philosophies is whether relies on a mix of in-band and out-of-band 
data, or exclusively on out-of-band data. The latter approach is 
intrinsically unable to respond to route changes in real time (if we 
assume that out-of-band data is not made available in realtime to 
routers) and thus can deal only with what might be legitimate under 
some circumstances.

You are right that the use of the phrase  "has the update traveled 
the path" suggests a more realtime approach, but this is the 
definition from the BGP spec, not a side issue. If BGP does not rely 
on this notion, if it is irrelevant, we have had several years to 
remove it from the spec, yet it persists. The requirements document 
has several areas where operational considerations have held sway, 
and one can justify this because they are areas where the BGP spec 
(and ancillary specs like community definitions) do not impose 
requirements. The issue is whether fundamental definitions from BGP 
are to be ignored because we worry about meeting these requirements.

As for the example, the issue is not whether C and indicates (via out 
of band means) that the path via B is valid for specific NLRI. The 
question is whether this info also says that the path via D is valid 
for the same NLRI. If so, then either path will pass the "it is a 
valid path" test and we are vulnerable to attacks that express the 
second path, even when C has not advertised it. So, no, an 
out-of-band approach, if it not realtime or near realtime, is not 
equivalent to an in-band approach, in terms of security functionality.

I rarely think that a vague definition is a good one :-), especially 
in a requirements document.

Steve

---

From: Paul Jakma <[email-masked]>
Date: Tue, 27 Sep 2005 04:01:47 +0100 (IST)

On Mon, 26 Sep 2005, Stephen Kent wrote:

> Paul,
>
> You're right that not everyone agrees with the need to verify 
> routes as advertised vs. how they might be advertised. But, the 
> reasons for the disagreement are rarely clearly articulated. Often 
> there is an underlying current of "the only ways we know how to do 
> X seem too expensive, so we can't make X a requirement."

Exploring the different costs of different approaches and weighing 
them against their benefits seems like something which will have to 
do be done.

> I appreciate the concern over the viability of proposed solutions, 
> but a requirements document that is tailored to accommodate what 
> some folks believe is possible at a given point in time runs the 
> risk of being arbitrary and quickly outdated.

Leaving the valid in "Is the AS_PATH valid?" as undefined is hardly 
likely to become outdated. However trying to /define/ "valid" in the 
requirements document is what seems arbitrary to me (and 
prejudicial).

> Also, there are many folks who have expressed the view that a 
> scheme that relies on all ISPs to publish their policies in enough 
> detail to support the "it could be a legitimate route" model is a 
> non-starter too. So we have expressions of groups of folks who

Sure, that's one of the main disadvantages to that approach.

> intrinsically unable to respond to route changes in real time (if 
> we assume that out-of-band data is not made available in realtime 
> to routers) and thus can deal only with what might be legitimate 
> under some circumstances.

As far as I know that assumption is not correct (the out-of-band 
channel likely would still use BGP as a transport) hence I think the 
real-time argument possibly doesn't quite hold.

> definition from the BGP spec, not a side issue. If BGP does not 
> rely on this notion, if it is irrelevant, we have had several years 
> to remove it from the spec, yet it persists.

You're saying the BGP specification defines that any security 
solution should validate that the update has traveled the path? 
Sorry, but I don't think so. ;). I thought it was the task of this WG 
to determine..

> community definitions) do not impose requirements. The issue is 
> whether fundamental definitions from BGP are to be ignored because 
> we worry about meeting these requirements.

The BGP spec says nothing about these security solutions though. The 
point here surely is not so much as to establish the veracity of the 
information in an attribute with respect to how it was propogated nor 
to establish the plausibility of AS_PATH via some other means, but 
the rather more abstract goal to make BGP as a /system/ secure 
(aforementioned mechanisms being two possible ways towards achieving 
this ;) ).

To prejudge the solution by framing the requirements tightly and 
toward one mechanism isn't really cricket.

> The question is whether this info also says that the path via D is 
> valid for the same NLRI. If so, then either path will pass the "it 
> is a valid path" test and we are vulnerable to attacks that express 
> the second path, even when C has not advertised it.

That might be perfectly acceptable though. That's one of the things 
to determine, no?

> I rarely think that a vague definition is a good one :-), 
> especially in a requirements document.

Well, is it to be a requirements document for solutions for securing 
the BGP system in general, or a requirements document more specific 
to one of the proposed solutions? ;)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"Don't discount flying pigs before you have good air defense."
-- [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Sep 2005 10:42:40 -0400

>them against their benefits seems like something which will have to 

Yes, but we're writing a requirements document not choosing a 
solution. Tradeoffs based on specific solutions are not within the 
purview of this document.

>requirements document is what seems arbitrary to me (and 

Yes, an undefined term will not become outdated :-), but it is also a 
continuing source of contention and confusion. I've rarely heard 
anyone seriously suggest that employing an undefined term in a 
requirements document is a good idea.

>real-time argument possibly doesn't quite hold.

We disagree on what the assumptions are for out-of-band approaches, 
which may be illustrative of the problems we all face when we start 
judging requirements based on our perceptions of the implied solution 
space!

We have had agreement that a solution must not assume that routers 
have to have highly reliable, real-time communication with new 
entities. So, use of BGP to distribute security data, but having it 
be a separate channel, e.g., for backward compatibility, would not 
violate that notion, so long as the BGP connections are with the same 
set of routers as before. However, if the data being sent via these 
parallel connections is based on relatively static info acquired from 
servers, then the problems I cited still apply.

>Sorry, but I don't think so. ;). I thought it was the task of this 
>WG to determine..

The WG is not redefining BGP semantics. It is supposed to define 
security requirements for BGP and my position is that we should be 
doing so based on published standards, tempered by operational 
experience. We ought not create our own notions of what security 
means for BGP within this WG, independent of these bases.

>information in an attribute with respect to how it was propogated 
>nor to establish the plausibility of AS_PATH via some other means, 
>but the rather more abstract goal to make BGP as a /system/ secure 

You are right that BGP says very little about security, but it does 
try to define what correct operation of BGP is, under benign 
circumstances. Our goal is to try to support correct operation under 
hostile circumstances. Probably the best one can hope to achieve is 
to allow routers to detect deviations from correct operation and to 
respond in a fashion dictated by local policy.  What the AS-path in 
an UPDATE means is central to BGP, defined in the spec, and thus 
merits our attention.

>toward one mechanism isn't really cricket.

Yes, this has been a problem for some time. I was not a contributor 
to the initial versions of this document.  Russ White was, and he is 
a strong proponent of one solution approach. My comments have tried 
to improve the document ion general, and to counter what I perceive 
as biases introduced by others, in  support of their favored 
solutions.

>That might be perfectly acceptable though. That's one of the things 

Yes, it is fair to debate this tradeoff, either now or in a solutions WG.

>to one of the proposed solutions? ;)

It is supposed to be generic, but we have continuing disagreements 
about the extent to which authors introduce solution-centric biases 
into the document.

Steve