Subject: Re: [RPSEC] draft-ietf-rpsec-bgpsecrec-06.txt

From: Curtis Villamizar <[email-masked]>
Date: Fri, 21 Jul 2006 15:20:06 -0400

In message <[email-masked]>
Iljitsch van Beijnum writes:
>  
> On 21-jul-2006, at 2:41, Curtis Villamizar wrote:
>  
> >> I wouldn't want my routers to carry information that I can't  
> >> inspect...
>  
> > Do you block IPSEC flows too?  :-)
>  
> That's different. Either the packets are addressed at one of my  
> hosts, which will hopefully be able to decrypt them, or someone is  
> paying me to carry carry them and they don't want me to look inside,  
> which I don't find unreasonable.
>  
> I'm not saying that encryption can have no place in inter-domain  
> routing ever under any circumstance, but the burden of proof of why  
> this would be a good thing is firmly on the people who may want this.  
> The possible argument that otherwise someone may see a private  
> routing policy utterly fails to convince me.

I gave an example.

> > How would you know its encrypted if it was in an optional transitive
> > attribute that your router didn't understand?  And why would you care
> > if your big government customer needed it but you didn't?
>  
> I would care if I peer with you and YOUR big government customer  
> injects the stuff and pays you good money for the privilege, but I  
> don't see any of that money but I do need to buy more memory to store  
> this stuff even though it's encrypted so by definition I have no use  
> for it.
>  
> Things are different when we don't peer but you buy transit from  
> me.  :-)
>  
> [...]

If provider A and C both had government customers and provider B
didn't and had to carry 1 MB of extra attributes in their router with
1-4 GB or memory, I doubt they'd even notice.

If the entire Internet carried lots of extra per hop authentication it
would be a burden.

We are dicsussing a hypothetical and getting off topic.  If you don't
mind leaving the "authenticated (or encrypted)" in the wording then we
can move on.

> >> That is not necessarily an ideal situation. This means encoding the
> >> security information in path attributes, which means that BGP tables
> >> in existing routers will be inflated without benefit to those
> >> existing routers.
>  
> > You are right in a sense.  But I disagree.
>  
> > It depends on the size of these extra attributes.  Some of the
> > proposals add so much information that I don't see it as feasible
> > except in a small closed network.  If people want to define protocols
> > that no one will ever deploy and whose attributes will be tossed
> > that's their business.  They've been at it for a while though.
>  
> "Anyone with a keyboard and time on their hands can write an internet  
> draft." Sure. But what we're trying to do here is come up with  
> something that is useful for wide deployment throughout the internet.

We are coming up with a requirements document at this point.  I'm
trying to accomodate is that one set of security mechanisms will be
appropriate for the Innternet at large.  Another set of security
mechanisms will be appropriate for applications requiring a higher
degree of security.  It might even come to a country by country or
provider by provider mixed deployment.

On that topic I suspect that the Internet will end up with a model of
origin authentication and transitive trust.  Some groups, notably
government and military will want better security and require per hop
authentication.  The latter may be infeasible in the entire Internet
due to its resource requirements.

Currently we have a set of somewhat conflicting requirement.  There
really is no way to provide strong encryption with no impact on memory
and CPU loading and no change in deployed equipment.  RPSEC work needs
to plan well for a partial deployment and mixed solutions.

> >> It would certainly be a bad idea to carry information in path
> >> attributes that is invalidated as soon as it is relayed by a non-
> >> upgraded router. (This is just an example of a bad idea.)
>  
> > If authentication information is all that is added to BGP then tossing
> > *all* the authentication information is certainly a bad idea.
>  
> That's not what I was saying. What I mean is: suppose a new system  
> includes a way to authenticate the AS path by requiring each AS/ 
> router to sign its changes to the AS path. Now there is a non- 
> upgraded AS in the middle. Obviously this makes it impossible to  
> authenticate the AS path in this manner. This makes it unnecessary  
> and therefore harmful to include the AS path authentication  
> information when sending an update to a non-upgraded router.

I gave an example where it might be useful to not toss this
information even if nothing is added to it.

> > What might make sense is to toss any per hop path authentication
> > before advertising to a router that would not add its authentication.
>  
> Right!

Except that you haven't read the next few paragraphs yet.

> > That would make sense if policy was based only on prefering a route
> > with a completely authenticated path over one that is not complete but
> > did not prefer paths with less hops not authenticated over ones with
> > more hops not authenticated.  OTOH if a completely authenticated path
> > was not available a path with only AS from a small set of fairly well
> > trusted AS in it might be preferred over one with more untrusted AS.
>  
> Sure. But we have to be careful about injecting huge amounts of  
> authentication data just in case someone somewhere might find it  
> marginally useful. Not sending what we know won't be useful is the  
> first step here, operator control should take care of the rest.
>  
> > Removing information because it won't be needed downstream could be
> > considered a configurable space optimization.  Sound like I need a
> > SHOULD in that paragraph, making it.
>  
> >>>   1.  The security information SHOULD be passed intact but
> >>>       uninterpreted across routers that did not support the same
> >>>       security mechanism.
>  
> > Is that better?
>  
> No, this requires stuff that may or may not be useful.

SHOULD does not require anything.  MUST would require it.  This allows
for the possibility of tossing the information if there was reason to
do so, such as the information was too big to carry.

> If it's a good idea to include the information, I think we can trust  
> the people designing solutions to make this happen. We shouldn't  
> require them to do it just because it _might_ be useful.

That's why I used SHOULD.  Would you like to suggest better wording?

> >>> If the route selection is modified based on level of trust, an  
> >>> entire
> >>> AS MUST implement the same route selection to avoid loops.
>  
> >> This is not a requirement in existing BGP and I don't see how adding
> >> security imposes this as a requirement.
>  
> > All routers must implement the same route selection algorithm.  That
> > is a requirement of plain old BGP.  The exact route selection
> > algorithm is defined in RFC4271.
>  
> Ah, but my routers still run RFC 1771.  :-)

But the route selection in RFC4271 reflects reality where the route
selection defined in RFC1771 was too loosely defined and was deviated
from in virtually *all* routers on the market.  They all interoperated
becasue they supported options that could make the route selection the
same within an AS.  They could be configured such that route selection
differed and could create persistent route loops.

> RFC 4271:
>  
>        If the route is learned from an internal peer, either the  
> value of
>        the LOCAL_PREF attribute is taken as the degree of preference, or
>        the local system computes the degree of preference of the route
>        based on preconfigured policy information.  Note that the latter
>        may result in formation of persistent routing loops.
>  
> So apparently having different route selection criteria inside the  
> same AS is allowed, even though the new RFC claims this can lead to  
> loops, which isn't true: this may lead to state where there is no  
> stable convergence, but (persistent) loops shouldn't happen.

The route selection is exactly the same.  The method of setting
incoming LOCAL_PREF can differ.  LOCAL_PREF is the first thing
considered.  Try reading section 9.1 in its entirety and carefully.

LOCAL_PREF is used only in IBGP.  One router sets LOCAL_PREF on any
given route.  All routers consider LOCAL_PREF first in route
selection.  Route selection is the same throughout the AS as described
in "9.1.2.  Phase 2: Route Selection".

> > This is stating that if within an AS
> > the route selection defined in RFC4271 is not used, it has to be the
> > same throughout the AS.
>  
> I don't think so. Where does it say this?

If you change route selection, meaning what is described in "Phase 2:
Route Selection", you have to do so with extreme care.  Now if you
reread what I wrote it might make a bit more sense to you.

BGP terms can be a little non-obvious but "route selection" means what
is written in "9.1.2.  Phase 2: Route Selection".  It does not mean
setting LOCAL_PREF.

Below is the original text that you took apart.  Your point is taken
and I added the sentence referencing LOCAL_PREF (third sentence) and
added to the next sentence.  Does it make more sense now?

   Given the above properties, a router could implement policy which
   considered the above levels of trust.  This routing policy could
   determine whether to accept the route.  This routing policy could
   impact the calculation of degree of preference (setting of BGP
   LOCAL_PREF) as described in RFC4271 in "9.1.1.  Phase 1:
   Calculation of Degree of Preference".  This routing policy could
   modify the route selection as described in RFC4271 in "9.1.2.
   Phase 2: Route Selection".

   If the route selection is modified based on level of trust, an
   entire AS MUST implement the same route selection to avoid loops.
   Orderly transition of the AS must be considered.  Note that one way
   to accomplish a transition that if free of persitant loops during
   the transition is to make the route selection change conditional on
   the absence of an intra-AS BGP community which is set on every
   route during the transition, then removed.  The transition then
   occurs on a per route basis as the BGP community is removed.  To
   accompish an orderly transition using this method, BGP community
   MUST be supported by the implementation in any policy that modifies
   the route selection.

Curtis

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jul 2006 16:45:36 -0400

At 3:20 PM -0400 7/21/06, Curtis Villamizar wrote:
>...

This WG has not come to consensus on what is "appropriate" for 
Internet at large, so trying to refine requirements based on one's 
perception of that is likely to cause us to fail to make progress.

>due to its resource requirements.

And I would argue that since transitive trust is precisely what 
allows errors by one ISP to screw up routing by many other ISPs, we 
ought to outlaw solutions that rely on this notion. So, we have a 
simple example of two conflicting views of what represents 
"appropriate" security for the public Internet, which is why we have 
tried to avoid details like this in the requirements document.

>to plan well for a partial deployment and mixed solutions.

presumably you were envisioning to crypto operations other than 
"encryption" above, since the proposals that have been put forth do 
not make any use of encryption.

>  ...

Steve

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 23 Jul 2006 12:51:07 +0200

> 1-4 GB or memory, I doubt they'd even notice.

Guess what: not every router has a gigabyte or more memory. And some  
routers get two, three, four or even more views of the global routing  
table. We can't afford to be cavalier about this even though  
obviously the internet won't crash and burn at the first sign of some  
extra data in BGP path attributes.

> provider by provider mixed deployment.

Unless I'm seriously overlooking something, today, operators  
generally can't filter out unwanted unknown path attributes. I don't  
see how we can assume that those would be contained.

> SHOULD does not require anything.  MUST would require it.

Semantics. SHOULD in a requirements document is a very strong statement.

> differed and could create persistent route loops.

The way I understand it, RFC 4271 is supposed to reflect the way BGP  
is actually deployed (well, at least to a larger degree than RFC 1771  
does) and all BGP implementations that I've worked with (6 in the  
last few years, some more exotic stuff longer ago) allow the user to  
tweak the way in which routes are selected such that different  
routers in the same AS make different choices. (They also have minor  
differences in the actual algorithm.) This is normal and doesn't lead  
to loops except for very short transient ones during convergence,  
even if you configure router A to prefer the path over router B and  
router B to prefer the path over router A.

> considered.  Try reading section 9.1 in its entirety and carefully.

I'm happy with my understanding of the text. Please quote the  
specific sentence that supports your claims.

> in "9.1.2.  Phase 2: Route Selection".

What is "used" supposed to mean here? Local preference is only  
_communicated_ through iBGP, but routers also consider the local  
preference in decisions about routes learned over eBGP.

"All routers" apparently doesn't include Cisco routers:

1. Prefer the path with the highest WEIGHT.

http://www.cisco.com/warp/public/459/25.shtml

I have no idea what "route selection is the same throught the AS" is  
supposed to mean. Does it mean that throughout the AS, the highest  
local preference is preferred? That seems rather obvious. Or does it  
mean that throughout the AS, all routers must set the local  
preference in the same way? That's not how things work in practice,  
it's impossible to enforce and I'll be happy to argue why it's the  
wrong thing to want to happen in the first place but who cares.

> reread what I wrote it might make a bit more sense to you.

What this says is:

       a) the highest degree of preference of any route to the same set
          of destinations, or

       b) is the only route to that destination, or

       c) is selected as a result of the Phase 2 tie breaking rules
          specified in Section 9.1.2.2.

What exactly would you want to change here? It makes much more sense  
to fold any new rules into a), which is left upto policy in the first  
place.

>    entire AS MUST implement the same route selection to avoid loops.

BGP doesn't support persistent loops because of the requirement that  
you only announce the route you use yourself to others. Any  
mentioning of the need to avoid loops therefore serves no purpose and  
only confuses matters.

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 23 Jul 2006 13:41:20 -0400

In message <[email-masked]>
> extra data in BGP path attributes.

Most routers sold as core routers these days are upgradable to at
least 1 GB of route processor memory.  Plus you can change the route
processor in most or all of them if you have an older route processor
with 1/2 GB limit or less.  Given the investment in core routers, a
few RAM packages isn't much.

It is more likely that the tier-1 providers will be asked to provide
transport for those wanting very secure routing.  The tier-1 providers
tend to have big routers with adequate memory and 5 or more global
views in not uncommon.

> see how we can assume that those would be contained.

I guess that needs to be a requirement in this requirements document.

   Routers which understand the BGP attributes associated with a given
   security mechanism SHOULD be able to configure the security
   mechanism "off".  Routers which have the security mechanism
   configured to "off" SHOULD be configurable such that they will drop
   any BGP attribute associated with the security mechanism or pass
   that attribute along.

This makes it a choice available to each provider.  Better?

> Semantics. SHOULD in a requirements document is a very strong statement.

See above.  If the router doesn't understand it, pass it on.  If it
does understand it there are three choices.

  1.  Perform any necessary signature and pass on the attribute(s).

  2.  Pass on the attributes unchanged or with indication that they
      were not signed depending on the recommendations of the protocol.

  3.  Drop one or more of the attributes associated with a given
      security mechanism.  A small  attribute may be added or
      substituted depending on the recommendations of the protocol.

Again.  Better?

> router B to prefer the path over router A.

Many routers allow you to deviate from the RFC4271 route selection and
you do so at your own peril.  If you configure routers for different
route selections you almost certainly will get routing loops.  A few
routers have not been upgraded to make the default RFC4271 compliant.

> specific sentence that supports your claims.

   5.1.5.  LOCAL_PREF

   LOCAL_PREF is a well-known attribute that SHALL be included in all
   UPDATE messages that a given BGP speaker sends to other internal
   peers.  A BGP speaker SHALL calculate the degree of preference for
   each external route based on the locally-configured policy, and
   include the degree of preference when advertising a route to its
   internal peers.  The higher degree of preference MUST be preferred.
   A BGP speaker uses the degree of preference learned via LOCAL_PREF
   in its Decision Process (see Section 9.1.1).

   9.1.  Decision Process

   [...]

   Route selection then consists of the individual application of the
   degree of preference function to each feasible route, followed by
   the choice of the one with the highest degree of preference.

   [...]

   9.1.1.  Phase 1: Calculation of Degree of Preference

   The Phase 1 decision function is invoked whenever the local BGP
   speaker receives, from a peer, an UPDATE message that advertises a
   new route, a replacement route, or withdrawn routes.

      If the route is learned from an internal peer, either the value of

      If the route is learned from an external peer, then the local BGP
      speaker computes the degree of preference based on preconfigured
      policy information.  If the return value indicates the route is
      ineligible, the route MAY NOT serve as an input to the next phase
      of route selection; otherwise, the return value MUST be used as
      the LOCAL_PREF value in any IBGP readvertisement.

      The exact nature of this policy information, and the computation
      involved, is a local matter.

How to pick "degree of preference" is a local matter and done on an
EBGP route.  Then put that "degree of preference" into LOCAL_PREF.

On an IBGP route take LOCAL_PREF and that is your "degree of
preference".  Don't change it.  Note the text from the RFC.

   [...] or the local system computes the degree of preference of the
   route based on preconfigured policy information.  Note that the
   latter may result in formation of persistent routing loops.

LOCAL_PREF which is the same thing as "degree of preference" is the
first thing considered.  Note the text below.

   Route selection then consists of the individual application of the
   degree of preference function to each feasible route, followed by
   the choice of the one with the highest degree of preference.

   [...]

   9.1.2.  Phase 2: Route Selection

   [...]

   For each set of destinations for which a feasible route exists in the
   Adj-RIBs-In, the local BGP speaker identifies the route that has:

The tie breaking rules in 9.1.2.2 only apply if LOCAL_PREF which is
the same thing as "degree of preference" is the same.

> preference in decisions about routes learned over eBGP.

The LOCAL_PREF attribute is only sent when advertising BGP routes.
That is what "used" meant.  Sorry to be unclear.

Otherwise LOCAL_PREF and "degree of preference" are used somewhat
interchangeably.  If you learn an EBGP route the "degree of
preference" is what you would be setting LOCAL_PREF to be if you
advertised it into IBGP.

> http://www.cisco.com/warp/public/459/25.shtml

Also note very next sentence.

  Note: WEIGHT is a Cisco-specific parameter. It is local to the
  router on which it is configured.

Weights are normally assigned to an entire protocol.  You can really
hurt yourself fooling around with weights.

The next thing on the Cisco web page is LOCAL_PREF.

> wrong thing to want to happen in the first place but who cares.

If you set Cisco weights randomly you will get route loops.

You can set LOCAL_PREF to any value and not get route loops due to the
way LOCAL_PREF is handled by routers.

If you could configure one router to consider AS Path length before
LOCAL_PREF and you used LOCAL_PREF (didn't set it the same
everywhere), then you'd almost certainly get route loops.  Changing
the order in which LOCAL_PREF, AS Path length, MED, IGP cost, are
considered would be a change in the route selection algorithm.

Clear now?

> to fold any new rules into a), which is left upto policy in the first  

The route selection consists of the tie breaking rules in the rest of
the section.  This just says if there is more than one route with the
same "degree of preference" then continue with the tie breaking rules
in the remainder of Section 9.1.2.2, otherwise use the route with the
"highest degree of preference".

> mentioning of the need to avoid loops therefore serves no purpose and  

You obviously were not around or did not pay attention when there was
controversy over whether higher MED was preferred or lower MED or a
number of other cases where routers only advertised the routes they
were using but difference in the route selection implemented by
different vendors could cause route loops because the routers in the
middle of the AS decided which was best based on a different set of
rules.

"Only advertise the routes you use" is necessary but not sufficient to
prevent persistent routing loops.

Curtis

---

From: Russ White <[email-masked]>
Date: Sun, 23 Jul 2006 13:43:26 -0400

> tend to have big routers with adequate memory and 5 or more global

IMHO, I wouldn't count on having X amount of memory, etc, in a
requirements document. These sorts of things will vary at various times
and in various networks. Things change. Don't count on them being the
way they are in a specific network at this moment in time.

I would consider the entire discussion on "holding encryption in router
memory," or "additional attributes," completely out of scope from a
requirements perspective. Let's come up with real requirements from a
protocol/security standpoint, and then let the router vendors and
operators decide how much they're willing to accept in memory upgrades,
etc, when considering the various tradeoffs of the proposed systems.

:-)

Russ

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 24 Jul 2006 01:27:44 +0200

> few RAM packages isn't much.

This doesn't give you a license to inflate the state associated with  
the global routing table arbitrarily.

> This makes it a choice available to each provider.  Better?

You can't impose new requirements on existing protocols and  
implementations, so no, this doesn't help.

> hurt yourself fooling around with weights.

No, that's the (administrative) distance. Weight is used by Cisco to  
overrule the local preference to prefer locally sourced routes over  
all others.

> Clear now?

No.  :-)

Actually, all of it is surprisingly un-clear. But I think I see what  
the point of all these dire warnings is now. Consider:

A--B--C--D

where A and D prefer external paths to a certain destination and B  
prefers the path over D and C over A. So C will send packets for this  
destination to B and B will send them to C.

This problem is caused by the fact that iBGP has no loop detection  
but we knew that iBGP is broken for a long time. You can get around  
this by making sure that all the decision making rules between local  
preference and IGP path are the same on all routers, but that  
certainly wasn't true in practice in the past across different  
implementations (is a missing MED < 0, == 0, == MAXINT or > MAXINT?)  
or by observing some topology restrictions or by implementing a  
certain level of route reflection, and maybe in some other ways as well.

Too bad the new RFC doesn't explain this stuff, although with RFC  
4271 we now know that a missing MED is the lowest possible value,  
although2 in my book it says that the IETF mandates the opposite  
choice, too bad2 I didn't include a source for this little tidbit of  
information. (Also see RFC 4451.)

> number of other cases

I've never been on the IDR wg list because the day only has 24 hours  
and what happens there tends to be too detail-oriented for me to want  
to spend time on.

Oh yes, the point:

BGP and especially its operation is pretty complex as it is. We only  
need one requirement: don't break BGP! Everything else is a nice-to- 
have. Yes, this includes security! I'll take a not very secure  
network that works (the one we have now) over a secure one that  
doesn't any day of the week.

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 23 Jul 2006 22:09:18 -0400

In message <[email-masked]>
> the global routing table arbitrarily.

Quick to jump on me.  Yes I agree with you here.  Note that the very
next paragraph gives a way to avoid carrying information.

> implementations, so no, this doesn't help.

This is imposing a new requirement on a new BGP attribute defined for
a BGP security mechanism.  It is not a new requirement for an old
protocol.

I think we already mentioned the possibility of tossing the attribute
on the sender side.  This just adds the ability to toss the attribute
on the receiver side.

There is no alternative.  It doesn't seem like an option to require
that "BGP security mechanisms will define no new BGP attributes".

> overrule the local preference to prefer locally sourced routes over  

Or do anything else since it is available across protocols.

> > considered would be a change in the route selection algorithm.

I thought it would be.  But OK.

> doesn't any day of the week.

You are just going to have to accept that in BGP terminology setting
LOCAL_PREF value is not part of the route selection algorithm and that
the route selection algorithm can't be changed without changing it
everywhere otherwise persistent route loops can be formed.

Curtis

---

From: Russ White <[email-masked]>
Date: Mon, 24 Jul 2006 08:14:59 -0400

> that "BGP security mechanisms will define no new BGP attributes".

But there are ways around defining new attributes, so assuming one must
exist, or that it will be large, or cryptographic in nature, is also
assuming a solution.

Again, these are requirements, not solutions. How something is done has
nothing to do with what is done, technically. Don't assume an attribute,
don't assume not attribute. Don't assume anything, just consider what's
important, and what's not, and work from there.

> Or do anything else since it is available across protocols.

Weight is BGP specific. No other protocol has weight. It is before Local
Preference in the decision process, and has nothing to do with
administrative distance. Weight is local to the router, since it's not
sent in any packet. The primary place where I see weight in use is to
make certain uRPF works correctly for networks dual homed into to edges
of a single peering AS, but there are other uses that are valid, as well.

:-)

Russ

- --