Subject: [RPSEC] BGP Requirements Draft

From: Russ White <[email-masked]>
Date: Thu, 08 Sep 2005 19:11:55 -0400

Y'all:

We'd like to go to last call on draft-ietf-rpsec-bgpsecrec-02, of which 
the latest copy is here:

http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-02.txt

We'll look for the comment period to close by the 23rd of September, 
with a final goal of closing this doc before the next IETF.

Thanks!

Russ & Tony

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

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Sep 2005 09:16:29 -0400

My comments are attached as a PDF. Most are edits but a few deal with 
more significant, residual problems.

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 14 Sep 2005 11:21:19 -0400

My comments in general, and to Steve's comments, below.

:-)

Russ

- --

o Denial of service

....
Attacks against BGP may be used by an attacker to facilitate a wide
variety of active or passive wiretapping attacks against subscriber
traffic.

I noticed, when looking at Steve's suggested changes, the term 
"subscriber traffic" is used throughout the entire document. This 
assumes the most common (only) real use for BGP is in large Internet 
Service Provider environments, which isn't true.

In every instance where the term "subscriber traffic" is used, it should 
really be "traffic being forwarded through the network," or something 
similar.

- --

1.3 Areas to secure

....

An AS path is an UPDATE is deemed "valid" based on two criteria,
the first of which is less rigorous than the second.

I won't contest this wording here, although I believe it's stronglt 
arguable that the second criteria is actually _not_ more rigerous than 
the first, in the real world.

- --

Has the update actually traveled the path, as dictated by the BGP spec?

The term "BGP spec" should be replaced with a reference to the BGP 
specification itself. Second, the BGP spec doesn't dictate a specific 
routing update has actually traversed the AS' listed in the AS Path 
contained in a routing update. So, a better wording here is:

Has the update acutally travelled the path, as the operation of the BGP 
protocols outlined [BGP] infers it SHOULD have?

- --

2. Underlying Assumptions regarding BGP

....

It is important to note that an UPDATE message itself generally is not
re-transmitted.

Steve adds "generally" here. In reality, I don't know of a single
implementation of BGP that takes an update off the wire, and
retransmits it intact to any peer. All implementations actually
destroy the update as it is received, store the information in various
local tables, and then build a new update, with completely different
information, possibly, to send to peers. In reality the language here
should be strengthened, rather than weakened, as the insertion of
"generally" does.

- --

The BGP spec states that certain data in the message (e.g., AS_PATH)
is supposed to be forwarded transitively, but operational practice
sometimes diverges from the spec in this regard.

The "BGP spec" says no such thing. :-) Replace this with:

[BGP] infers that any received routing information has passed through
the AS Path indicated in the routing update itself by stating that any
BGP speaker advertising routing information to another BGP speaker
outside its local autonomous system SHOULD add the local AS to the AS
Path. In operational practice, there are many situations where [BGP]
is not strictly followed in this regard.

- --

Some operators insert a remote AS number in an UPDATE, in order to
cause the UPDATE to be dropped by that AS, so that traffic will not
traverse a given path. This practice is not condoned by BGP
specifications , but anecdotal evidence suggests that its use is not
totally insignificant.

Replace the last sentence with:

"This practice diverges from [BGP]'s specified handling of the AS Path 
when processing routing information being advertised to a BGP speaker 
outside the local AS, but...."

- --

In an environment where both secured and non-secured systems are
interoperating, a mechanism MUST exist for secured systems to
identify whether an originator intended the information to be
secured.

Steve asked:

Does this refer to the origin AS of the peer who sent an UPDATE? The
latter is feasible, the former seems to conflict with the previous
requirement for backward compatible formats in mixed environments.

My understanding of this was it related to the origin AS. Possibly 
reword to:

In an environment where both secured and non-secured systems are
interoperating, a mechanism MUST exist for secured systems to identify
whether the originator of the routing information (the originating AS)
intended the information to be secured.

- --

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Sep 2005 16:31:30 -0400

Russ,

>really be "traffic being forwarded through the network," or something

I did not make the assumption you cite. I used the term to refer to 
the entities who are the users of the network, whether the public 
Internet of not.

>protocols outlined [BGP] infers it SHOULD have?

I agree that a cite of the latest BGP I-D is preferable. However, 
your second comment conflicts with section 4.3 of that document, 
which says that the As-PATH is " ... the set of ASes a route in the 
UPDATE message has traversed ..."

>should be strengthened, rather than weakened, as the insertion of

Fair point.
>is not strictly followed in this regard.

Note the section 4.3 text I cited above, plus text in section 5 that 
says "Once a BGP peer has updated any well-known attributes, it MUST 
pass these attributes in any updates it transmits to its peers." The 
AS-PATH is a well-known attribute, right?

>intended the information to be secured.

It seems reasonable to assume that an AS be configured to know 
whether each of its neighbors is running a secure routing protocol, 
so the former interpretation makes sense.  The interpretation you 
propose has the quality that an AS that originates an UPDATE and 
wants it to be secure cannot do so if, for example, all of it's 
neighbors don't support routing security mechanisms. So, expressing 
the intent of the originator in this context seems almost pointless.

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 14 Sep 2005 16:49:28 -0400

> I did not make the assumption you cite. I used the term to refer to the 
> entities who are the users of the network, whether the public Internet 
> of not.

Well, the concept of a "subscriber" implies the concept of a "provider." 
I don't think that's true in all networks.

> I agree that a cite of the latest BGP I-D is preferable. However, your 
> second comment conflicts with section 4.3 of that document, which says 
> that the As-PATH is " ... the set of ASes a route in the UPDATE message 
> has traversed ..."

Sure, but it's not a "must," as we've discussed before. If it were a 
"must," this should be listed as a failure in specification compliance 
on every known BGP implementation currently deployed. I think the 
general feeling is it's a "strong should," but not a "must," which means 
the BGP draft really doesn't stipulate it, it just says that's the way 
it should be.

I suppose a weaker word than "stipulate" might work here, since that 
seems to read into the draft, and into the implementations that all 
interpretations of that draft, something that doesn't seem to be there, 
from the perspective of every implementor.

> AS-PATH is a well-known attribute, right?

Sure, but that doesn't mean the speaker cannot modify those attributes. 
Again, implementations don't work this way, or providers wouldn't have 
the option of doing the things discussed in this doc, so.... :-) I just 
want to make certain we reflect reality, not what's ideal--it's not what 
we think the BGP docs should say, it's what the implementors and 
operators have built based on that doc, as well, that plays into this.

> It seems reasonable to assume that an AS be configured to know whether 
> each of its neighbors is running a secure routing protocol, so the 
> former interpretation makes sense.  The interpretation you propose has 
> the quality that an AS that originates an UPDATE and wants it to be 
> secure cannot do so if, for example, all of it's neighbors don't support 
> routing security mechanisms. So, expressing the intent of the originator 
> in this context seems almost pointless.

Possibly, or possibly not... It's hard to say. I think this was oriented 
towards the entire piece on incremental deployment (?). I would say it 
seems like a good idea to be able to tell if information you've received 
from your neighbor has had stuff stripped from it that would secure it 
in some way (?).

:-)

Russ

- --

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Sep 2005 17:17:16 -0400

Russ,

The BGP spec it clearly states that the path carried in an UPDATE is 
the one that the UPDATE traversed as the underlying assumption. The 
protocol, as designed, is unable to detect deviations from the 
assumption, so making it a MUST for the protocol made no sense. 
However, since we are discussing security requirements for BGP we 
need to ask whether the clearly stated intent of the protocol is 
something that we should now try to secure.

We're again having the argument of whether the principle basis for 
BGP security requirements should be IETF-approved specs or 
implementor/operator behavior.  I recall that this is the point at 
which I asked if the IESG needed to intervene to help settle the 
argument.  Shall we go through that again?

As for the origin vs. neighbor AS security issue, knowing if data 
used to secure an UPDATE has been tampered with, including complete 
removal, is of interest, but that's a way of characterizing an 
attack, rather than  stating a security requirement. The wording in 
the document is too vague to be a good basis for a requirement, e.g., 
it does not clearly state what "information" an originator that 
implements BGP security is intending to secure.  We need better 
wording here.

Steve

---

From: Russ White <[email-masked]>
Date: Wed, 14 Sep 2005 18:32:31 -0400

> The BGP spec it clearly states that the path carried in an UPDATE is the 
> one that the UPDATE traversed as the underlying assumption. The 
> assumption, so making it a MUST for the protocol made no sense. However, 
> since we are discussing security requirements for BGP we need to ask 
> whether the clearly stated intent of the protocol is something that we 
> should now try to secure.

There are no implementations that support your reading of the draft, 
which implies I'm not the only one who reads the BGP specification this 
way. People have valid reasons for changing the AS Path, including 
adding and removing information from the AS Path.

> We're again having the argument of whether the principle basis for BGP 
> security requirements should be IETF-approved specs or 
> implementor/operator behavior.  I recall that this is the point at which 
> I asked if the IESG needed to intervene to help settle the argument.  
> Shall we go through that again?

It's up to you if you want to have this argument. I only pointed out two 
things among many that show the draft implies this should be the case, 
but recognizes it may not always be the case. My primary suggestion here 
is that we not say: "The BGP specification requires routing information 
to have traversed the AS Path listed in the received update," because 
operators don't use it that way, and implementors don't implement it 
that way.

I believe we've already had the argument about building requirements 
based on the "specification alone," or on a combination of the 
specification combined with real world experience and operator 
requirements, and got to the point we are now. I would prefer we not 
rehash that decision, if possible, since we've been actually making 
progress on the requirements document up to this point, and I don't 
think a recurrance of that argument is going to help us continue 
progressing it.

> As for the origin vs. neighbor AS security issue, knowing if data used 
> to secure an UPDATE has been tampered with, including complete removal, 
> is of interest, but that's a way of characterizing an attack, rather 
> than  stating a security requirement. The wording in the document is too 
> vague to be a good basis for a requirement, e.g., it does not clearly 
> state what "information" an originator that implements BGP security is 
> intending to secure.  We need better wording here.

It seems to me the requirement is based around the ability of a receiver 
of a route to know whether the originator of that route (not the 
advertiser, the originator), originally advertised or included any 
information that would validate their origination authorization and, 
possibly, policies. I don't think that's an unreasonable requirement in 
a mixed environment, and it's not an attack, it's a defense against a 
possible attack.

:-)

Russ

- --

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Sep 2005 20:53:39 -0400

At 6:32 PM -0400 9/14/05, Russ White wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>

Russ, it's not my reading of the draft, it is a clearly worded 
definition in the document. If it's so obviously wrong then you 
should have brought that up during last call, many month ago.

>think a recurrance of that argument is going to help us continue

Well, we obviously didn't come to the same conclusions about the 
outcome of the argument. Alex stepped in to obviate the IESG decision 
I requested and we did make progress, so I let the matter drop, but 
we can pursue it again, if you insist that operator behavior must be 
the basis for this requirements document, rather than an 
IESG-approved spec that is sitting in the RFC Equtor's queue after 
years of work.

>a mixed environment, and it's not an attack, it's a defense against a

It's not an unreasonable argument, if one assumes a specific 
implementation strategy, which a requirements document ought not do. 
And yes, the words you specifically used last time were an attack 
characterization, because they focused on tampering with the data, 
rather than stating a positive characteristic. The text above is more 
appropriate, yet it still is solution specific, i.e., it calls for 
inclusion of data in the UPDATE to validate origination 
authorization, rather than  saying that data must be available to a 
receiver of an UPDATE to enable it to validate ...  The difference in 
wording is important because it expresses the requirement in  a 
solution-independent fashion.

Steve

---

From: Russ White <[email-masked]>
Date: Thu, 15 Sep 2005 07:05:49 -0400

> Russ, it's not_ my_ reading of the draft, it is a clearly worded 
> definition in the document. If it's so obviously wrong then you should 
> have brought that up during last call, many month ago.

Juniper and Cisco, at least, allow adding things to the AS Path other 
than your own AS number. Operators use this feature in both cases. 
Further, it's impossible to prevent someone from simply reoriginating a 
route without an AS Path, in any implementation, especially when the 
re-originated route is a superset (aggregate) of an existing learned 
route. This removes information from the AS Path. Therefore, regardless 
of your reading of the draft, the ability to add and remove information 
from the AS Path exists in the real world, today, in widely deployed 
implementations.

Now, your real contention is that any given security system should 
disallow these actions, under the assumption that it would make BGP 
"more secure." This leaves us with two questions:

- -- Would it make BGP "more secure?" Since all security is a tradeoff, 
the answer to this question must be weighed along with the next one.

- -- Would requiring this cause a major upheaval in the routing system as 
it exists today? What are the costs? What are the security holes created 
by implementing this specific concept?

I believe these two questions should be left to the decision makers 
designing the system and the operators, not to some esoteric definition 
of "perfect security in a perfect world."

The document, as it sits, makes a good balance by noting there are two 
types of tests you can perform on the AS Path. Adding the additional 
text about "what the BGP spec requires" simply overrides that entire 
discussion, and attempts to put in one of those two tests as the only 
valid test. The balance is there for a reason, and my suggestion is that 
we leave it in place, rather than inserting text elsewhere that upsets it.

> Well, we obviously didn't come to the same conclusions about the outcome 
> of the argument. Alex stepped in to obviate the IESG decision I 
> requested and we did make progress, so I let the matter drop, but we can 
> pursue it again, if you insist that operator behavior must be the basis 
> for this requirements document, rather than an IESG-approved spec that 
> is sitting in the RFC Equtor's queue after years of work.

I've looked through the discussion on the list, and the conclusion, as 
far as I can see, was that the current BGP specification, tempered by 
operator requirements and implementations, should be the basis for the 
draft.

:-)

Russ

- --

---

From: Stefan Mink <[email-masked]>
Date: Thu, 22 Sep 2005 09:44:56 +0200

Hi all,

> with a final goal of closing this doc before the next IETF.

Steve already did a decent job and covered many points I found
as well, so I only repeat the most important ones here...

new points/questions:

* 1.3:
   * "The originator and the propagators... may have their routing
      preference .. information verified..."
      I'm not sure I understand the meaning of this sentence.
      What is the exact attack we want to protect us against?

   * I would (as Steve) replace the term "viable path" by "valid path".
     In the next section the "validation of the as-path" is
     covered, where the "viability" is again coverd, so this
     seams redundant right now.

   * An additional validation on the as-path is:
     "Has every AS on the path been authorized to pass the route
     on to the next AS? (this authorization is based on inter-
     provider contracts)". Otherwise we can not protect against
     redistribution attacks (I can provide an example if this is
     not clear).

* 2.:
   * "While the AS_PATH information is typically transitive it is,
      currently, not clearly mandated and many times is removed for
      various utilitarian reasons". What does this mean? (Steve
      deleted this as well)
   * s/rightmost/last/ ?
   * A further example for AS-path mangeling is integration of an
     AS (after acquisition) into an existing AS. Routers use one
     "proxy AS" (ASa) in the communication to a peer, but internally
     use another AS (ASb). Here two ASes ("ASa ASb") are inserted
     into the path before announcing a route via eBGP), although
     ASa not exists as a distinct network anymore.
   * "...to effect forwarding changes..." and "... to effect for-
      warding and routing changes...": Why do we talk here about
      "changes" and why do we talk about "forwarding" in one case
      and about "forwarding and routing" in the other? In my eyes
      "to influence routing decisions" would be better in both
      cases. I would keep to routing and not talk about implicit
      effects on the forwarding plane.
   * "Route Origination:" Should we add a reference to Whois/RPSL/
      RPSS here? When the RIR uses RPSS (e.g. as RIPE is doing),
      origin validation can be done already today.
* 3.2
   * "Message formatting in a fully secured environment..." and
     " intermediate routers which don't support the new format"
     seem contradictory to me. Maybe we can be more precise
     here.

* 4.
   * s/following criteria/following requirements/

* 6.
   * additional point to "The following items are required to
     propagate at the same rate":
     "inter-provider authorization information"

* 9.
   * "and that the AS's lsited in the AS_PATH actually forwarded
      the update": In 6. we have 4 possible checks which are
     reduced to one check here. Should we refer to 6. here?

   tschuess
        Stefan

-- 
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Stefan Mink <[email-masked]>
Date: Thu, 22 Sep 2005 09:55:09 +0200

> really be "traffic being forwarded through the network," or something 

s/subscriber/end user/?

> the first, in the real world.

I think the second is more rigerous: the first point checks, whether
the path actually exists, the second point whether the UPDATE actually
travels the path. This is an additional check to me, so the check is
more rigorous.

> is not strictly followed in this regard.

fine with me.

> outside the local AS, but...."

another proposal:
"This practice abuses the loop check in absence of other means to
 enforce the local policy, that this route is not to be used in
 the targeted AS."

> intended the information to be secured.

ack.

   tschuess
             Stefan Mink

---

From: Russ White <[email-masked]>
Date: Fri, 23 Sep 2005 09:09:29 -0400

>      redistribution attacks (I can provide an example if this is

There's no way to state any AS along the AS Path has been authorized to 
retransmit routing information it's received. The first question that 
comes to mind is: "Authorized by whom?" The originator probably doesn't 
even know about tan AS four hops away, so it's a little difficult to 
authorize someone you don't know about to advertise something. Second, 
once you take aggregation into account, it's impossible to say: "I've 
received 10.1.0.0/16, which means that the sender of this route is 
authorized by the owner of 10.1.1.0/24 to advertise 10.1.1.0/24 (which 
is a part of 10.1.0.0/16)." Authorization isn't really transitive in 
that sense in BGP. So, in short, I would disagree with this wording. :-)

>       various utilitarian reasons". What does this mean? (Steve

I don't know--is the first AS in the Path the one that was just added, 
or the originator? :-)

>      ASa not exists as a distinct network anymore.

This is quite common with AS transition techniques, I believe.

>       effects on the forwarding plane.

Yep.

>       origin validation can be done already today.

I don't think so, since that's a solution, rather than a requirement.

>      reduced to one check here. Should we refer to 6. here?

No. We shouldn't require the verification that the routing information 
traversed the AS_PATH, since there are tradeoffs with any such scheme of 
"additional security" (which, as I've asserted elsewhere, amounts to 
non-repudiation, and nothing else) against deployability. This tradeoff 
should not be resolved in this requirements document, but rather by the 
solution designer.

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Fri, 23 Sep 2005 09:11:47 -0400

> travels the path. This is an additional check to me, so the check is

It's not, really. In the "pure" sense, in a system without aggregation 
and filtering, it is more rigorous. In the real world, where 
aggregation, ECMP, and filtering are all done "in due course," any 
benefit gained quickly falls out, other than "non-repudiation" (however 
you'd like to define that term).

:-)

Russ

- --

---

From: Stefan Mink <[email-masked]>
Date: Fri, 23 Sep 2005 16:00:21 +0200

> you'd like to define that term).

These points are valid for end user traffic and wether they
really follow a route end-to-end or not. I don't see the relevance
for the path of a route which was not forwarded end-to-end like
user packets but which passed on via several "sections" between
routers. Aggregation/ECMP/filtering doesn't play a role between
EBGP peers and it hardly plays a role between IBGP peers.

Whether the second check is more rigorous or not depends on wether
we see a security benefit in the result, that a route really was
forwarded _by exactly the ASes in the path_ and _in exactly
that order_ :
* Do we care whether additional ASes (which never handeled
  this route) were inserted?
* Do we care wether ASes have been deleted?
* Do we care wether someone mixed the path up and changed
  the order of the ASes?

If we don't care about these points, the second check is indeed
less rigorous, but then we could also drop it because its
result is insignificant :]

   tschuess
             Stefan

---

From: Russ White <[email-masked]>
Date: Fri, 23 Sep 2005 10:25:27 -0400

>   this route) were inserted?

The first check already covers this in the "pure" case, when you discuss 
a single routing update, no aggregation, etc. In the aggregation case, 
suppose you have this:

10.1.1.0/24 {1,2}
10.1.2.0/24 {3,4}

Aggregates to:

10.1.0.0/16 {x,[1,2,3,4]}

Now, which subset of 10.1.0.0/16 did 1, 2, 3, and 4 actually touch? The 
entire /16 obviously isn't the correct answer. With the use of AS Sets 
for ECMP being considered, this makes things even worse in this area 
(and, BTW, there's nothing in the BGP spec today that would prevent AS 
Sets from being used by any given implementation for ECMP, or just 
creating an AS Set from the received AS Path without doing any 
aggregation of any sort).

> * Do we care wether ASes have been deleted?

The first check also checks this, in the "pure" sense, when you discuss 
a single routing update, no aggregate, etc. In the aggregation case, 
suppose you have 10.1.0.0/24 and 10.1.1.0/24, and you simply reoriginate 
10.1.0.0/23? Haven't you removed information from the AS Path? You can 
argue that this is a "new advertisement," reducing us to the first case, 
but it's not really true, since 10.1.1.0/24 is contained within 
10.1.0.0/23, and yet may have completely different policies, etc. As the 
receiver of a route, you have no idea how many actual subnets actually 
"live within" that route, where they are divided, and what the policies 
for each one of those subsets might happen to be.

Or, suppose you have 10.1.1.0/24 {1,2}, and 10.1.1.0/24 {3,4}, and 
simply filter 10.1.1.0/24 {1,2}. Haven't you removed information from 
the list of AS' that have "touched" this routing information?

> * Do we care wether someone mixed the path up and changed

The first check also checks this, in the "pure" sense, when you discuss 
a single routing update, no aggregate, etc. In the AS Set case, the 
ordering of the AS' doesn't matter.

> result is insignificant :]

The problem is, there is rampant disagreement here--is the "pure" sense 
the one we should be after, or the "real world?" Are the requirements 
based on a reading of the actual language of one specific part of the 
BGP specification, and not the way it's actually deployed? Perhaps a 
better question would be: Should the requirements be based on the entire 
BGP specification, including the portions of aggregation, filtering, 
etc, or should they be based on one specific sentence within the BGP 
specification, without reference to the remainder of the BGP 
capabilities covered in the specification?

:-)

Russ

- --

---

From: Stefan Mink <[email-masked]>
Date: Fri, 23 Sep 2005 16:53:49 +0200

Russ White wrote:
> retransmit routing information it's received. 

thats correct at the moment. It is also correct that we don't have
any means to find out, wether somebody is authorized to originate
a route or not. At least there is no PKI as proposed in SBGP/soBGP/
psBGP :]

Nevertheless, this could be _a requirement_ although we don't have
a solution right now. I also don't say it's a MUST...

> The first question that 

I give you an attack example against which I want to defend,
maybe you find a better wording for requirements which make
this attack impossible:

AS A is customer of AS B, AS C is a customer of AS D.
Now AS B and AS D establish a BGP session and contractually
clarify that the exchanged routes are only to be used for
the receiving AS itself and its customers.

For now, AS D only sees it's own traffic to AS A/B and
the the traffic of it's customer to AS A/B. This is
all legitimate, nobody got attacked on the routing plane
so far.

Now AS D want's to attack traffic between a not-customer
AS E it is connected to and AS A. Since that traffic is
not flowing through AS D by normal means, AS D has to
influence the routing plane, e.g. it readvertises the
routes received from AS B to AS E so chances are, that
AS E uses these routes and forwards packets via AS D to
AS A/B. I call this a "redistribution attack" since AS D
illegtimately handles routing information.

By the way: a similiar attack could also be launched
by AS D by originating a route for the relevant target,
e.g. AS A: create a route, set the as path to "AS A AS D"
and announce it to AS E. Whether AS D now blackholes
the packets flowing to it for this destination or passes
it on via other means so they eventually reach their
destination nevertheless is secondare here.

For me, both szenarios are szenarios resulting in the
same attack on data plane (against which we want to
defend I hope :]). The second one is covered by the
requirements in the draft, the first one is not.

> I don't know--is the first AS in the Path the one that was just added, 

RFC1771 states, that "the local system shall prepend its own AS number
 as the last element of the sequence (put it in the leftmost position)."

So "last" is wrong and it would have to be "first" :]

Nevertheless "first" and "last" is more intuitive when talking about
sequences. Although I didn't managed it here, I think it's easier
to remember that
   "last" means "last AS inserted"
than
   "rightmost" means "last AS inserted"

Its a matter of taste...

> should not be resolved in this requirements document, but rather by the 

so we should drop the passage?

   tschuess
             Stefan

---

From: Stephen Kent <[email-masked]>
Date: Fri, 23 Sep 2005 11:06:10 -0400

Russ,

We have had this discussion several times before, and it's 
disappointing that we seem to be back at ground zero again.

I have argued that if AS A sends an UPDATE to As B, and does not mark 
the UPDATE as being NO-EXPORT, then that constitutes authorization 
for AS B to advertise the route in  the UPDATE. You have never 
provided  what I (and several others) consider to be a good counter 
argument to this interpretation of BGP semantics.

>  The first question that
>comes to mind is: "Authorized by whom?"

By the neighbor who sent the UPDATE, for the reasons noted above.

>The originator probably doesn't
>authorize someone you don't know about to advertise something.

agreed, the originator did not directly authorize later hops.

>  Second,

This is a confusing example that does not seem to support your argument.

>should not be resolved in this requirements document, but rather by the

You noted that the text from the current BGP RFC that I cited didn't 
use the term "MUST."  I should have responded that the text in 
question is a definition, and thus it is not surprising that 
MUST/SHOULD is not used. Definitions are fundamental precepts for 
protocols.

The use of the term "non-repudiation" is still inappropriate in this 
context, for the reasons that I (and others) have note in previous 
messages.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 23 Sep 2005 11:08:16 -0400

>you'd like to define that term).

If you don't use a term as it is defined in the relevant literature, 
and you leave it to other to interpret, the use of the term is more 
or less meaningless.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 23 Sep 2005 11:14:08 -0400

At 7:05 AM -0400 9/15/05, Russ White wrote:
>"more secure."

That's not what I said, Russ, and your inference of what I contend is 
incorrect.  We already know that appending multiple instances of ones 
own AS # is explicitly allowed in the latest BGP spec. That does not 
really violate the spirit of the definition I cited since the path, 
when the adjacent AS#  repetitions are collapsed, is still consistent 
with the path traversed by the UPDATE. The same is true for appending 
multiple instances of the AS # of the neighbor from whom an UPDATE is 
received, although this is not explicitly called out by the spec. If 
one abandons the notion of an UPDATE having followed the path it 
contains, then all sorts of behavior is potentially allowed, which is 
hardly a desirable security trait.

>This leaves us with two questions:
>

the line of argument you begin here is spurious. the question of 
whether A is more secure than B may be evaluated independent of the 
tradeoffs. perhaps what you meant to say was that even is A is more 
secure than B, one may prefer A once the non-security aspects of A 
and B have been evaluated. Russ, our debates could be more productive 
if you were more precise in your comments.

>of "perfect security in a perfect world."

whenever I hear someone refer to "perfect security" I start to worry. 
We know that all of the proposals for BGP security have residual 
vulnerabilities. nobody is arguing for a set of requirements that 
would yield perfect security, so you're comment is a red herring.

>we leave it in place, rather than inserting text elsewhere that upsets it.

The current text represents an imbalance, with too much deference to 
"operational" practice.

>...

the question is whether violating a basic definition from the BGP 
spec is within the "tempering" you we agreed to to achieve the 
desired balance, or whether it is such a substantial deviation from 
the basic concepts of BGP that is upsets this balance.

Steve