Subject: Re: [RPSEC] proposed message to the IESG

From: Sandy Murphy <[email-masked]>
Date: Thu, 20 Jan 2005 17:22:03 -0500 (EST)

>2. BGP spec not followed: I believe the crux of this discussion is that by
>adding additional requirements to the way BGP currently works (to take into
>account operational practice) we are improperly specifying the requirements.

It's really tough to analyze stuff that's not written down anywhere,
even as written in some implementations, and isn't followed the
same everywhere.

I've been in too many idr and rpsec working groups listening to 
people contradict each other at the mike to believe that operational
practice is anywhere near homogeneous ("no one does this" "hey, wait
my whole operation depends on that").  Case in point: recent
discussion about deprecating flap dampening or not.

Anyone want to take on the task of writing up the current operational
practice?

Then there's the fact that operational practice changes to cope with
operational environment.

--Sandy

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

---

From: Blaine Christian <[email-masked]>
Date: Thu, 20 Jan 2005 17:37:58 -0500

> even as written in some implementations, and isn't followed the

You have that right.  Just a few years ago implementing vendor X next to
vendor Y was quite entertaining.  BGP is a bit loose.  Of course it is also
quite well used and considering it's scope of deployment it is a pretty
impressive feat.

> discussion about deprecating flap dampening or not.

I could not agree more.  BGP has a LOT of wiggle room in it.  This must make
security oriented folks nuts.  I am only into security operationally.
However, I have quite a bit of background in the "hey your implementation of
BGP broke me" realm.  Heck, a lot of times it was our specific manner of
implementing BGP that broke people (MED route oscillation due to
confederations comes to mind).  While we will probably not be able to come
up with a complete requirement that solves everything I do firmly believe we
can improve the current state of affairs while letting the older
implementations age out gracefully.

> Anyone want to take on the task of writing up the current operational

I am not biting on that one.  I already did one of those on traffic
engineering <grin>.  Funny enough, I actually had an operator approach me
after one presentation stating that they want the ability to insert an AS
that belongs to another operator into their advertisement in order to block
reachability for that AS!

> Then there's the fact that operational practice changes to cope with

That is a very good point.  I have talked about this in the past.  If a
sufficient number of big vendors agree on an implementation they can
probably make it happen (unless it is completely nuts).  This has happened
more times than I can count.  The operators will find ways to work around
things.  However, operators also vote with their money and those who accede
to the needs of the operators in the most effective way will win the market
and the protocol wars.

---

From: Russ White <[email-masked]>
Date: Thu, 20 Jan 2005 18:44:25 -0500 (Eastern Standard Time)

IMHO, any security system not flexible enough to change with operational 
changes isn't really that good of a security system. :-)

>> 2. BGP spec not followed: I believe the crux of this discussion is that 
>> by adding additional requirements to the way BGP currently works (to 
>> take into account operational practice) we are improperly specifying the 
>> requirements.
>
> It's really tough to analyze stuff that's not written down anywhere, even 
> as written in some implementations, and isn't followed the same 
> everywhere.

There are some general things we can surmize that I don't think _need_ to 
be written down. These assumptions should, probably, be in the draft, and 
they probably aren't there today, but they aren't much that anyone would 
contest.

-- Address allocation is generally done by some controlling authority, but 
is then distributed to sub-authorities. For political reasons, we can't 
always expect the chain of authorization to be "friendly." In other words, 
you can't always expect the allocator and the allocatee (??) to be on any 
more than formal contractural terms, and that it will often cost money to 
get more services.

-- Overlapping address spaces exist. Filtering of routing information is 
commone practice.

Any others?

> I've been in too many idr and rpsec working groups listening to people 
> contradict each other at the mike to believe that operational practice is 
> anywhere near homogeneous ("no one does this" "hey, wait my whole 
> operation depends on that").  Case in point: recent discussion about 
> deprecating flap dampening or not.

Goodness, I hope no-one deprecates dampening!

:-)

Russ

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