Subject: Re: [Idr] Next revision of AS_HOPCOUNT

From: [email-masked]
Date: Wed, 11 Jan 2006 12:55:57 -0500 (EST)

>The other main mechanism which restricts route propagation (the  
>NO_EXPORT community string attribute) is trivial to strip from  
>routes, overriding the intentions of the previous AS in the path. In  
>general, surely every AS has a legitimate case for modifying the  
>attributes on prefixes to suit its own needs.

As I understand it, the NO_EXPORT attribute is intended just
for your immediate neighbor, and is not supposed to be propagated
elsewhere.  There's this "MUST NOT be advertised" in the spec.

Security mechanisms typically try to ensure that behavior matches
the spec or assumptions in the specs.  So the trivial strippability
(and subsequent propagation) would be a security vulnerability.

>What kind of modification would you consider inappropriate?

Oh, you know, any modification in violation of what the spec says
should be done.  Like changing the value from 3 to 15 (in the static
upper bound case) or incrementing the value by 6 instead of
decrementing by 1 (in the decremented case).

It is tough to operate a distributed system when you are putting
values in packets that are supposed to elicit certain behaviors
in all recipients and some recipients break the rules and do
something else entirely.

>I would expect any AS to be able to remove an AS_PATHLIMIT attribute  
>if that suited their local policy, substituting a new one if desired.  

AS_PATHLIMIT is a value that is supposed to affect ASes some distance
away and prevent propagation of information past a certain point.
Saying in the spec "but other ASes are free to do anything they want
to this field" seems to me to limit its usefulness.  It would make
"the control that we hope to achieve" (to quote the i-d) a rather
undeterministic sort of control.  Why bother with a "oh, who knows,
this might have some effect someplaces, then again, maybe not"
specification for what the field means?

Or maybe you intend the field to be advice rather than prescription?

If you would rather have a more deterministic semantics for
the field, then you probably would want some integrity protection
for the value.

If you want to permit a "maybe, maybe not" semantics to the field,
then you don't need the integrity.

If you set a AS_PATHLIMIT of 4 and the AS four hops away strips that
and adds a AS_PATHLIMIT of 15, would that be OK?  You write into the
spec whether that would be OK, and the security protections try to
make the decision enforceable.

--Sandy

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

---

From: Danny McPherson <[email-masked]>
Date: Wed, 11 Jan 2006 12:32:45 -0700

On Jan 11, 2006, at 10:55 AM, [email-masked] wrote:

> elsewhere.

That'd be NO_ADVERTISE.

> There's this "MUST NOT be advertised" in the spec.

In reality, NO_EXPORT in practice is employed to convey to
AN ADJACENT AS that the route should not be advertised to
BGP peers outside of that AS (i.e., eBGP peers).

> (and subsequent propagation) would be a security vulnerability.

In this case, deployability is dictated by each operators policy
independently.  I.e., you desire for this to be the intended function
and hope your peers respect that behavior.  However, if your
peer disagrees with you about how they should operate their
network (e.g., not accepting MEDs, modifying paths, stripping
communities) then their not having the capability to enforce their
own policies would be a security vulnerability.

Fortunately, most folks realize this and leave it as a matter of
implementation support and each network operators policies.

> in all recipients and some recipients break the rules and do

This distributed system is enabled and controlled by the folks
operating the networks, not providing those folks with the
capabilities to implement what policies they see fit for their
environment (i.e., rather than allowing their peers/competitors
to manipulate their network policies) is, well, not an option.

This is no different than any other attribute.  For example, if
an upstream chooses not to announce a route, well, there's
little we can do about that.

> and adds a AS_PATHLIMIT of 15, would that be OK?

Sure, why not?  If I'm the 4th AS and have reason to do so?  I own
my network resources?

-danny

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 11 Jan 2006 14:51:34 -0500

> Sure, why not?  If I'm the 4th AS and have reason to do so?  I own

But you don't own the resources of the person who'll eventually
receive the traffic.  I can certainly see a shady economic argument
that you'd want to disrespect control communities, even well recognized
ones, in order to sink more traffic across your network.  In many
cases, this would lead to increased revenue being exchanged between
AS 3 and AS 4.  AS 1, on the other hand, receives more traffic than
they may have wanted on that link.

In the case where different routes that would affect flow across
your network (A and B), I can see some justification to ignore
downstream preferences because you may want to manage your own
resources.  This justification is vague because AS_PATH is usually
a bigger knob to adjust these flows.

In the case of communities, I can see the semi-justification that
some policy languages make it difficult to "strip everything but
well known communities".

I can see the justification that you'd want to decrease the length
in order to further constrain the diameter to which the routes propagate.

I'm having a difficult time seeing (aside from the reasons above)
why you'd otherwise want to increase the diameter of propagation.
If you could expand on such possible reasons, I think a lot of us
would appreciate it. 

-- 
Jeff Haas 
NextHop Technologies

---

From: Danny McPherson <[email-masked]>
Date: Wed, 11 Jan 2006 14:38:58 -0700

On Jan 11, 2006, at 12:51 PM, Jeffrey Haas wrote:
> ones, in order to sink more traffic across your network.

or vice versa..  I wouldn't call it shady though, I'd call it practical
and reality.

> In many

I could make arguments for each of the above but it's futile.

My point is simply that as a network operator I have policies that
I employ on my network that are driven by both technical AND
business requirements, either of which may drive me to ignore,
strip or manipulate any attribute that could have an impact on the
operations of my business.  In short, I decide what route I provide
transit for and how I'll permit the TE-associated attributes of those
routes impact my network resources - AND who I allow to modify
those resources.

Now, with that said, operators of course realize what makes
practical sense and what doesn't, and they clearly factor that into
their policies.

The fact that BGP provides this capability is a large contributor to
it's success, IMO.

-danny