Subject: [RPSEC] issue: attributes

From: Sandy Murphy <[email-masked]>
Date: Tue, 8 Mar 2005 13:56:06 -0500 (EST)

I note that the draft section on the AS_PATH attribute currently says:

   Attributes such as local pref are locally
   specific and, as such, are protected by BGP session security.

Is this intended to cover all attributes other than AS_PATH?

Is it true to say both that all other attributes are locally specific
and that the session security is therefore sufficient (my own
interpretation of this sentence)?

If we are to cover other specs than the base spec, then we need to
consider the security requirements of other attributes, which aren't
necessarily locally specific.  Like considering the communities
attribute -- I've seen suggestions in a couple of places that
communities can be misused to effect traffic flow (including one old
1999 presentation at the blackhat conference and the Cisco BGPv4
Security Essentials paper, dated 2004).  With the NOPEER community
attribute, misuse has the potential to effect remote AS's (as RFC3765
notes).

But even if we stick to base spec attributes, the session security
might not be sufficient.  E.g., I have heard discussions that NEXT_HOP
can be mis-used to cause harm:

    A---B---C

B is peering with A and C but does not intend to provide transit.
A and C establish their own peering session and exchange UPDATES
with a B address listed as NEXT_HOP.

If this behavior still a problem, is there a requirement that could be
incorporated into the security requirements?

--Sandy

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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 8 Mar 2005 14:50:21 -0500

Sandy,

As you note, some attributes should have only local significance, but 
others are intended to be propagated beyond a neighbor AS. We also 
need to pay attention to the semantics of local attributes, in that 
it is desirable to enable an AS to detect if a prior AS did not 
behave in a way consistent with a local attribute. The obvious case 
here is the NO-EXPORT community attribute, which should be only 
locally significant, but it would be nice to know if AS path info was 
propagated contrary to the express wishes of a speaker.

It seems appropriate to identify which attributes fall into which 
category, as a starting point. Then we should decide whether we want 
to require or recommend that solutions provide a facility for a 
speaker to apply protection to attributes in a fashion that supports 
the underlying semantics.

Steve