Subject: [RPSEC] Basis of Requirements?

From: Russ White <[email-masked]>
Date: Tue, 27 Sep 2005 05:05:06 -0400

Y'all:

I've seen this:

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

Bandied about, with the concept that unless "the update has traversed 
the path," any given solution is not based on the BGP specification. I 
will counter this, as I always do, with a bit of clear thinking. Suppose 
we have a system thus:

A---B---C

A sends a bit of information to B. Now, we can treat this bit of data as 
  an "opaque type," and ask: "How can we verify that A has authorized B 
to send this bit of data to C?" This is one way of looking at the 
problem, focusing on one or two paragraphs within the BGP specification, 
and without any concept of what that actual "bit of data" is.

The other option is to examine the entire BGP specification, and temper 
it with real world experience with the BGP protocol. This sort of 
approach leads to the question: "What is in this bit of data??" Well, 
what happens to be in there is reachability information, including some 
policy, and some stuff to prevent looping of data being passed through 
the network. Now, the questions become things like:

- -- How can C be certain B has a path to A? That C isn't lying?
- -- Can know know whether or not B is authorized to transit traffic to 
the destinations it's advertising?

These are questions of a completely different character. The first 
concept treats BGP as an opaque transport system, without regard to what 
it is that BGP is actually carrying. This is okay for things like IPsec, 
but it's not okay for routing. In fact, treating BGP this way ignores 
large parts of the BGP specification, including the parts that actually 
define what the data BGP carries is. The second treats BGP as a system, 
and allows for the termpering of any given solution based on real world 
usage and experience.

Yes, they are different worldviews. Yes, they are both based on reading 
the BGP specificatio. One attempts to see how BGP works, the other what 
BGP does. Constantly repeating that one side wants to "base requirements 
on the BGP specification" while the other side wants to "base 
requirements on transient deployments of the protocol" will not make it 
so, no matter how many times you want to repeat it. There are two ways 
of looking at the BGP protocol, as a transport system, or as a routing 
system. Pick which one makes the most sense in the real world, but don't 
simply keep repeating over and over and over and over that one of them 
is not a realistic reading of the BGP specification.

:-)

Russ

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

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

---

From: Stefan Mink <[email-masked]>
Date: Tue, 27 Sep 2005 12:14:11 +0200

Hi Russ,

Russ White wrote:
> -- How can C be certain B has a path to A? That C isn't lying?

just to be sure I got you right, I guess this should read
"That B isn't lying"

> -- Can know know whether or not B is authorized to transit traffic to 

I don't see any problems in doing checks for each of these questions
since they are each important and even base on each other:
Asking the second question doesn't make any sense without asking
the first question. Thats why I proposed:

 * 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).

(so far nobody could show me that this makes no sense, only that
 its very hard to do; thats why I would not make it mandatory).

-> check 1: does the path exist?
         2: does the update actually travel this path?
         3: was this path authorized?

> is not a realistic reading of the BGP specification.

Just securing the BGP protocol will us lead nowhere IMHO. The
BGP protocol doesn't know the concept of "origin authorization"
and neither "redistribution authorization" which are exactly
the points, where attacks target the Internet routing today.

We have means to protect BGP against outsiders by using TCP-MD5
or even IPsec. To protect against insiders - which becomes
more and more important - just authenticating routing data but
not being able to verify the contents is not enough to secure
routing substantially.

   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: Stephen Kent <[email-masked]>
Date: Tue, 27 Sep 2005 10:54:36 -0400

At 5:05 AM -0400 9/27/05, Russ White wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Y'all:
>
>I've seen this:
>
>- -

I am very much aware of the meaning of the "bit of data" in question. 
The BGP RFC is also quite clear about the semantics associated with 
this data. Thus it is inaccurate to criticize my argument on this 
basis.

>the network. Now, the questions become things like:

Now you are looking at only aspect of the BGP spec, i.e., focusing 
only on the anti-looping aspect of the AS path info.

>
>- -- How can C be certain B has a path to A?

BGP describes what is supposed to happen  under benign circumstances, 
i.e., under the assumption that B is not lying. Our job is to try to 
extent these semantics described to hostile environments.

>  That C isn't lying?

C is the recipient of the advertisement in your example, so this 
question makes no sense.  If you meant that B isn't lying, that would 
make sense, and I answered that question above.

>the destinations it's advertising?

BGP addresses the notion of authorization implicitly, as I have 
explained, with cites to the BGP RFC, on many occasions in the past

>and allows for the termpering of any given solution based on real world

Your argument is based on characterizing what I propose as ignoring 
the meaning of BGP data, e.g., AS path info.  But I am the one 
pointing out what the BGP RFC defines as the meaning of this data, 
and suggesting that we base our requirements on that. Instead what 
you suggest is that we base the security on operational practices 
that are not standardized, not uniformly articulated by the 
operations community, and IETF-approved. The debate on this list over 
the extent to which route poisoning is used and whether such use is 
legitimate and important is an example of the lack of a solid basis 
on which to formulate requirements based primarily on operational 
practices!

>is not a realistic reading of the BGP specification.

Russ, I object to your attempt to frame my arguments as based on 
ignorance of what the routing system is trying to do. The argument is 
grossly inaccurate.

Steve

---

From: Russ White <[email-masked]>
Date: Tue, 27 Sep 2005 11:37:30 -0400

> extent these semantics described to hostile environments.

Are the semantics that B has sent a specific data as 'authorized" by A, 
or that B sends reachability information to C. Are the semantics of BGP 
the way this information is transmitted, or the reachability information 
A sent in the first place, and the transit implied in sending that 
information along to C?

As I said, there are two different worldviews here.

IMHO, the draft, as it sits today, balances these two views well. There 
are specific pieces of wording that I don't agree with, but I 
specifically asked for a last call knowing I didn't agree with every 
last thing in the draft. We can either go for balance, or we can argue 
for the next three years about "the basis of the requirements," knowing 
full well there are several possible alternate readings of the level and 
sense of the BGP specification.

I think it's time to last call the doc, and move forward. We won't 
achieve perfection.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Sep 2005 12:02:23 -0400

At 11:37 AM -0400 9/27/05, Russ White wrote:
>>BGP describes what is supposed to happen  under benign 
>>circumstances, i.e., under the assumption that B is not lying. Our 
>>job is to try to extent these semantics described to hostile 
>>environments.
>
>Are the semantics that B has sent a specific data as 'authorized" by 
>A, or that B sends reachability information to C. Are the semantics 
>of BGP the way this information is transmitted, or the reachability 
>information A sent in the first place, and the transit implied in 
>sending that information along to C?

THE BGP spec says that the AS path in a received UPDATE represents 
the path traversed by UPDATEs that carried this info, with each AS 
adding itself to the path as the data was passed along. Most folks 
who read this, plus the ancillary specs on community attributes like 
NO-EXPORT, agree that the path represents authorization by each AS to 
the next, to advertise the NLRI contained in the route.

>As I said, there are two different worldviews here.

but only one of the world views is based on IETF-approved documents ...

>IMHO, the draft, as it sits today, balances these two views well. 
>There are specific pieces of wording that I don't agree with, but I 
>last thing in the draft. We can either go for balance, or we can 
>argue for the next three years about "the basis of the 
>requirements," knowing full well there are several possible 
>alternate readings of the level and sense of the BGP specification.
>

Consider my comments as objections to the state of the document in last call.

As WG co-chair you and Tony get to decide whether there is WG 
consensus on the document as it stands, at the end of the last call, 
unless you choose to recuse yourself from the decision to avoid the 
perception of conflict of interest.

Steve

---

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

On Tue, 27 Sep 2005, Stephen Kent wrote:

> adding itself to the path as the data was passed along.

That isn't what it says though, it says it represents the path 
traversed by the /route/ - not the UPDATE.

And they can easily differ.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Gary Hart:  living proof that you *can* screw your brains out.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Sep 2005 14:37:05 -0400

>And they can easily differ.

A route is defined in BGP as AS path info and the associated NLRI.

BGP transmits routes only via UPDATEs.

What are some examples of how a path traversed by a "route" is 
different from the one traversed by the UPDATEs that carry the As 
path info and NLRI that constitute a route?

Steve

---

From: Tony Tauber <[email-masked]>
Date: Tue, 27 Sep 2005 11:48:49 -0700 (PDT)

> Consider my comments as objections to the state of the document in

Folks,

Since it seems we're going around and around on the latest vibrant set
of comments, let's work on a clear vote on the document as it stands.

Please convey your opinion on whether this document should progress.
If an unqualified "yes" or "no" doesn't represent your view, please
try and _succinctly_ relate what would need to be changed for the
document to meet with your approval.

Tony

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 27 Sep 2005 14:51:39 -0400

> A route is defined in BGP as AS path info and the associated NLRI.

To be excruciatingly pedantic, a bgp route is NLRI + path attributes.
This includes more than the AS_PATH.

Path attributes are expected to change on a hop by hop basis.

We should be rather careful as to what we define, for purposes of
securing BGP, what we mean by a BGP route.

(Not picking specifically on Steve, but it was a convenient point to 
comment.)

-- 
Jeff Haas 
NextHop Technologies

---

From: Paul Jakma <[email-masked]>
Date: Tue, 27 Sep 2005 20:16:49 +0100 (IST)

> A route is defined in BGP as AS path info and the associated NLRI.

Not the AS_PATH, but the path /attributes/. Which a speaker is 
explicitely allowed to modify when readvertising.

> path info and NLRI that constitute a route?

One case where the AS_PATH would not fully describe the path taken 
would be transparent ASs, and/or private ASes. Also, as discussed 
already, aggregates also need not list all ASes. Nor does the 
definition of AS_PATH, to my reading at least, demand that /all/ ASes 
which the path traveled through be listed therein.

The latter (aggregates) may not be that important. The former 
(transparent-as), well you could argue an speaker not inserting their 
AS into the path would not be following the spec, and you'd be right 
of course ;), however in a similar fashion a speaker /receiving/ such 
a route which follows the spec has no reason to /reject/ such a route 
(ie the spec does /not/ say "thou shalt ensure the sender has 
inserted their ASN"). Strict in what you send, liberal in what you 
accept is good and tends to allow for creative extensions.

Eg, the transparent-as hack, or other uses of AS_PATH which /todays/ 
speakers would not originate, could easily be legitimised by future 
extensions.

The point isn't whether these specific hacks have value, but whether 
it is correct to interpret what today's speaker may have cause to 
send as hence being the only valid way to /ever/ form those 
attributes.

There is value in that ambiguity (what the draft says can be created, 
versus what it demands for receivers) possibly :). The various 
operational AS_PATH hacks (most of which, AIUI, were /not/ directly 
anticipated for AS_PATH initially) add weight to this view, no?

Anyway.. :)

This discussion possibly is log jammed and I don't really have an 
answer either, so I'll try bow out. ;)

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Nobody ever died from oven crude poisoning.

---

From: Tony Tauber <[email-masked]>
Date: Tue, 27 Sep 2005 12:19:30 -0700 (PDT)

> of comments, let's work on a clear vote on the document as it stands.

Actually, let's hold just a bit. I'd been working on integrating some
of the more formal (e.g. spelling and such) comments and we should
vote on a doc with those integrated.  Stay tuned.

Thanks,

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 27 Sep 2005 17:50:23 -0700

> Nor does the definition of AS_PATH, to my reading at least, demand  
that /all/ ASes which the
 > path traveled through be listed therein.

Well, the _intent_ of the document is that the AS_PATH contain _all_  
of the ASes.  This is obviously necessary for loop avoidance.

Tony

---

From: Russ White <[email-masked]>
Date: Tue, 27 Sep 2005 21:47:59 -0400

>> A, or that B sends reachability information to C. Are the semantics of 
>> BGP the way this information is transmitted, or the reachability 
> THE BGP spec says that the AS path in a received UPDATE represents the 
> path traversed by UPDATEs that carried this info, with each AS adding 
> itself to the path as the data was passed along. Most folks who read 
                                                    ^^^^
> this, plus the ancillary specs on community attributes like NO-EXPORT, 
> agree that the path represents authorization by each AS to the next, to 
> advertise the NLRI contained in the route.

Some. Most folks see this as a mechanism to prevent loops, not provide 
or trace authorization.

> but only one of the world views is based on IETF-approved documents ...

The intent of BGP is to provide reachability information, in the form of 
routes (a route is an NLRI and all attendant attributes, which may 
change hop by hop). Aggregation, filtering, AS Path prepending, 
re-origination, and communities all impact reachability information 
passed from AS to AS. Possession of some piece of routing information 
does not imply permission to retransmit that routing information; local 
contracts between owners of autonomous systems define this. These 
policies are implemented through manually configured filters and 
mechanisms like route communities. The AS Path is used for loop 
freeness, not to prove or validate an authorization chain; if an AS Path 
indicates an authorization chain, then AS Sets, aggregation, and other 
such constructs, make no sense. Further, if possession of a route 
indicates authorization to readvertise that routing information, then we 
should be concerned about the ability of an AS to block reachability 
information that a prior AS or peer explicitely wants forwarded, yet 
this was left out of the requirements and threat model as an "invalid 
attack." Nor does possession of reachability information imply, in all 
cases, authorization to transit a specific AS Path to reach a specific 
destination--it can't, because routing doesn't work that way.

IMHO, the evidence points to a different reading of the BGP 
specification than what you imply, much broader than a narrow focus on 
one specific attribute, and the concept of "authorization" tied up with 
that single attribute.

But, I think I've repeated myself enough here. I'm certain someone will 
come back and try to tear this argument apart, but that will just go 
back to what I said in the first place--there are two different 
worldviews at work here.

Let Tony T. finish his edits, and then we can take a vote on progressing 
this doc. We've been working on it for at least two years (as far back 
as September of 2003, based on the archives), and this has been a 
sticking point for that entire time--in fact, it's almost the only 
sticking point we've had for the last two years. Again, I don't think 
we're going to reach perfection, here, just some sort of document that 
comes as close as possible to accurately expressing both views.

:-)

Russ

- --

---

From: Tony Tauber <[email-masked]>
Date: Tue, 27 Sep 2005 21:21:24 -0700 (PDT)

On Tue, 27 Sep 2005, Tony Tauber wrote:

>> Folks,
>> 
>> Since it seems we're going around and around on the latest vibrant
>> set of comments, let's work on a clear vote on the document as it
>> stands.
>
> Actually, let's hold just a bit. I'd been working on integrating
> some of the more formal (e.g. spelling and such) comments and we
> should vote on a doc with those integrated.  Stay tuned.
>
> Thanks,
>
> Tony

OK, here's the version with the comments and corrections:

http://www.1-4-5.net/~ttauber/draft-ietf-rpsec-bgpsecrec-03.txt

Here are the diffs between -02 and this version:

http://www.1-4-5.net/~ttauber/draft-ietf-rpsec-bgpsecrec-02-03-diff.html

Please indicate whether or not this document is ready to progress.

Thanks,

Tony

---

From: Russ White <[email-masked]>
Date: Wed, 28 Sep 2005 08:51:07 -0400

> Please indicate whether or not this document is ready to progress.

I believe the doc is ready to progress.

:-)

Russ

- --

---

From: Blaine Christian <[email-masked]>
Date: Wed, 28 Sep 2005 10:08:29 -0400

$MoveForward += 1;

Assuming Tony does not kill me for complaining about grammar at the  
last minute.

On Sep 28, 2005, at 8:51 AM, Russ White wrote:

> -----BEGIN PGP SIGNATURE-----
> Version: PGP Desktop 9.0.2 (Build 2424)
>
> iQA/AwUBQzqRwhEdu7FIVPTkEQIwJwCg8Ze05z+yrXZXGMrvvTs6GlhW7AEAoPwe
> Nc5XpqWYU7nYKX39dQcWc+Q1
> =e90I
> -----END PGP SIGNATURE-----
>

---

From: Tony Tauber <[email-masked]>
Date: Wed, 28 Sep 2005 13:25:26 -0700 (PDT)

> Assuming Tony does not kill me for complaining about grammar at the

I'll settle for making you limp for a few days....

I incorporated these minor changes which only serve to make sense of
things which didn't otherwise. Thanks for the catch.

Tony

***************
*** 405,411 ****
         associated with that route is, in most cases, in conflict with the
         intent of the BGP specification, notable exceptions include:

!       *  Deployments that make route servers which are separate from
            forwarding devices

         *  Deployments that use the propagation of prefixes in order to
--- 405,411 ----
         associated with that route is, in most cases, in conflict with the
         intent of the BGP specification, notable exceptions include:

!       *  Deployments that use route servers which are separate from
            forwarding devices

         *  Deployments that use the propagation of prefixes in order to
***************
*** 508,513 ****

         formatting in a fully secured environment MAY be handled in a non-
         backward compatible fashion though care must be taken to ensure
!       when traversing intermediate routers which don't support the new
!       format.

--- 508,513 ----

         formatting in a fully secured environment MAY be handled in a non-
         backward compatible fashion though care must be taken to ensure
!       UPDATES can traverse intermediate routers which don't support the
!       new format.

***************
*** 802,808 ****
      Note that in today's operational Internet, the first two pieces of
      information, or their analogues, are not a part of the BGP routing
      system per se (e.g. information in Routing or Address registries.)
!    They are consulted by operators on an inconsistent basis and do are
      not consulted in real time by the routing system.  The third piece of
      information is explicitly carried in the routing system and
      inconsistently expressed and consulted by operators.  However, the
--- 802,808 ----
      Note that in today's operational Internet, the first two pieces of
      information, or their analogues, are not a part of the BGP routing
      system per se (e.g. information in Routing or Address registries.)
!    They are consulted by operators on an inconsistent basis and so are
      not consulted in real time by the routing system.  The third piece of
      information is explicitly carried in the routing system and
      inconsistently expressed and consulted by operators.  However, the

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 30 Sep 2005 16:09:54 +0200

Not ready, categorically.

I was waiting for a quiet moment on the list to raise concerns that do not
relate to AS-PATH and authorization such as:

scope - the only reference is to RFC 1771 and so implicitly the document is
about BGP only as defined there.  IMHO this is doubly wrong; first, it should be
about the revision of that RFC, since, after all, it was produced to bring the
specification in line with current practice; and second, there is the much
discussed but not agreed question of whether such things as Community should be
in there (eg NO_EXPORT) or not

keys- "automated means of managing keys MUST be available throughout BGP
security systems" for me leaves scope to generate stand-alone key management
systems such as SNMPv3 did, which have proved such a hit with operators that it
has rarely been deployed.  Rather, there should be a requirement that
standardised and widely deployed key management systems are used so that there
is integration with existing security systems (anyone familiar with isms will
known the pain behind this).

TLS gets a mention (along with IPsec) which I think a the wrong choice.  The
isms work
established that operators widely use SSH but there was no visible sign of TLS;
and that TLS alone would not provide authentication and would only be sufficient
with the addition of SASL.  So for me, the choice became a no-brainer.  SSH is
the required transport of Netconf (operators again) so if a transport level
security is needed, then I see the choice as a no brainer.  Of course this is a
detail for a later design but for the Requirements document to mention TLS and
not SSH sets this work off in the wrong direction.

etc etc etc

Tom Petch

---

From: Russ White <[email-masked]>
Date: Fri, 30 Sep 2005 11:59:50 -0400

> in there (eg NO_EXPORT) or not

I think we originally decided not to include other RFC's than 1771. I 
think the concensus has remained the same throughout.

The new draft is a valid point, but I believe this would be updated in 
the iesg process, so we could give the current bgp draft a chance to 
become rfc'd before referencing it. Maybe Alex or Bill would have more 
to say on the process.

> known the pain behind this).

I'll let someone who actually asked for this speak to it. We could drop 
this requirement, and it really wouldn't make much difference, to me, 
but I think there are others who strongly believe this should be a 
requirement.

> not SSH sets this work off in the wrong direction.

Dropping TLS would be fine, as well. I've always been a little confused 
as to why TLS was included, to be honest.

:-)

Russ

- --

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 30 Sep 2005 13:14:06 -0400

>become rfc'd before referencing it. Maybe Alex or Bill would have more 
Given that much of the debate is (at least nominally) about what the 
RFC says versus what happens in the real world, maybe we should wait.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Alex Zinin <[email-masked]>
Date: Fri, 30 Sep 2005 12:29:12 -0700

> become rfc'd before referencing it. Maybe Alex or Bill would have more 

The BGP spec update is on its way out of the RFC-Ed queue--we got a msg
from them yesterday asking about RFC number preferences. You can either
wait, or put "RFC ????" in the refs and it'll be fixed during the RFC
editor process.

--
Alex

---

From: Tony Tauber <[email-masked]>
Date: Fri, 30 Sep 2005 12:48:27 -0700 (PDT)

On Fri, 30 Sep 2005, Alex Zinin wrote:

> Russ wrote:
>> The new draft is a valid point, but I believe this would be updated
>> in the iesg process, so we could give the current bgp draft a
>> chance to become rfc'd before referencing it. Maybe Alex or Bill
>> would have more to say on the process.
>
> The BGP spec update is on its way out of the RFC-Ed queue--we got a
> msg from them yesterday asking about RFC number preferences.

Go for a vanity number, like 4444.

> You can either wait, or put "RFC ????" in the refs and it'll be
> fixed during the RFC editor process.

I'll take that as a replacement for RFC 1771 unles there are
objections.

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 30 Sep 2005 13:20:58 -0700

On Sep 30, 2005, at 12:29 PM, Alex Zinin wrote:

> msg

The update will be RFC 4271.

Tony

---

From: Alex Zinin <[email-masked]>
Date: Fri, 30 Sep 2005 14:18:56 -0700

> Go for a vanity number, like 4444.

Yeah, my thought too. From what we had Bill suggested 4271 (so it's
similar to the old 1771).

</off-topic> :)

--
Alex

---

From: Blaine Christian <[email-masked]>
Date: Fri, 30 Sep 2005 17:29:43 -0400

Sorry, I can't resist either...

<off-topic>

RFC 7117 would have a very similar symmetry though...  And you can  
say "similar symmetry" often...  There, doesn't that sound nice?   
"similar symmetry".   Mmm, alliteration...

</off-topic>

---

From: Stefan Mink <[email-masked]>
Date: Fri, 30 Sep 2005 23:38:24 +0200

> as to why TLS was included, to be honest.

this might be a little be offtopic, but AFAIK TLS closes the connection on
following events: incorrect MAC, invalid encryption (invalid length, invalid
padding), decompression failure (see RFC2246, page 26).

That sounds to me as if one could attack TLS easily by sending bullshit
data - of course you have to hit the tcp window, but following the discussion
about the rst attack, hitting somewhere into the window isn't very hard

That isn't probably a problem for web and other traffic, where the
connection has a short duration. For BGP these properties are a
real danger...

so: drop TLS...

    tschuess
              Stefan