BGP community based IP filtering

I've been having an email discussion with a couple of Cisco engineers about
how useful BGP community based IP filtering might be. The following IOS
config fragment might help explain what I'm getting at:

int fddi0
ip access-group community-list 10 in
!
ip community-list 10 permit AA:BB
ip community-list 10 permit CC:DD
!

If you are using communities to make your prefix announcements to peers,
this then allows the router to filter incoming IP packets that match your
announcements. Excepting things like CPU load, implementation details, etc
do you think this would be helpful, or am I way off with this?

Regards

Matt.

I've been having an email discussion with a couple of Cisco engineers about
how useful BGP community based IP filtering might be. The following IOS
config fragment might help explain what I'm getting at:

int fddi0
ip access-group community-list 10 in
!
ip community-list 10 permit AA:BB
ip community-list 10 permit CC:DD
!

If you are using communities to make your prefix announcements to peers,
this then allows the router to filter incoming IP packets that match your
announcements. Excepting things like CPU load, implementation details, etc
do you think this would be helpful, or am I way off with this?

  I think this would be helpful; especially if were scaled as a
  ubiquitous implementation mechanism.

  Further implementations of BGP community based decision criteria
  could include Class of Service/Type of Service Priority Setting; based
  upon a particular community, give packets with this network
  source/destination X priority.

  Additionally, other services such as selective NAT (do or do not
  NAT based upon communities, NAT into which address space based
  upon communities), etc... can be implemented.

  Similar to the regexp niftiness being put into access lists, it'd
  be keen to see all features using ACLs accept communities as
  determining factors.

  Bear in mind this is not terribly useful to the world if Cisco
  does it alone, it should be tracked through IETF, but it would be
  nice if Cisco did the proof-of-concept and led the pack.

  -alan

But isn't what you described implementation details? I'm not sure if I
see a standard to track in this... Perhaps a better venue to track
something like this is an IEPG/RIPE/IOPS/etc.

-dorian

You're absolutely correct. The current protocol requires no
  modification, it's just relevant to the way the router handles
  other services.

  The thrust of my goal, mangled as it was, was that this become
  fairly common and expected. If so, then one could communicate
  and act upon routes based upon their associated BGP communities.

  This, imho, would be a very good thing.

  -alan

Agreed. An operator community concensus to this affect to the vendors
would be a good thing.

I did not mean to dispute this point, and meant only to point out that
some venues are better than others for efforts such as this.

-dorian

Since you suggest IOPS as a body to track this issue, what do people think
about IOPS as a pseudo-standards group. This also came up at the December
IETF when Curtis suggested that draft-berkowitz-multirqmt document would
not be necessary since IOPS had a draft on the same subject. The IDR WG
seemed very sceptical of having a small closed body fill that role. How do
people see IOPS meshing with NANOG and the operational side of IETF?

thanks,
-chris

Well, sort of.. I just threw the name out there as a possibility, since
it exists. This was not in any way an endorsement of IOPS as anything more
than just that.

-dorian

I have a little bit of a problem when people refer to IOPS as a
"standards organization." A "standards" body needs to be open.

Is IOPS an open group? No.

Can anyone in the Internet community participate? No, they have to
be a member of the collective, and pay a membership fee ranging from
between US$9500 to US$25000.

IOPS is free to define all of the operations guides that they desire,
but it can't really be referred to as a "standards organization" since
it is a private club. :-/

- paul

ObDisclaimer: Standard caveats apply. Opinions are mine.

> But isn't what you described implementation details? I'm not sure if I
> see a standard to track in this... Perhaps a better venue to track
> something like this is an IEPG/RIPE/IOPS/etc.

Since you suggest IOPS as a body to track this issue, what do people think

Well, sort of.. I just threw the name out there as a possibility, since
it exists. This was not in any way an endorsement of IOPS as anything more
than just that.

-dorian

Haven't had a chance to follow up, but my head is now above water. I had
never heard of IOPS before.

From past experience with consortia, both inside and outside, I am a bit

uncomfortable with them in a standards-setting role compared with the
openness of IETF, IEPG, or NANOG. This is very pertinent to me at the
moment as I hunt for a new job, as it would be quite impractical for me
individually to participate in a group with significant up-front membership
fees. ARIN is a current example of that.

Way back when OSI Was The Answer, I used to work for the Corporation for
Open Systems -- in fact was the first technical person on staff. It had a
model where members had the only input, which may well have led to the
success of OSI.

I've watched various consortia first restrict access to documents, and see
an increasing trend in openness in such things as the ATM Forum.

Somehow, the networking community has managed to escape the tyranny of
Formal Standards Organizations. I well remember putting several
performance standards through ANSI, getting to the Public Comment phase,
and having to stop progressing the document until we responded formally to
the "Digital Communications Performance Parameters are all very nice, but
this document is flawed because it says nothing about saving the whales."
I am _quite_ serious.

So there is a delicate path to walk between the closed organization and the
standards bureaucracy.

It's my observation that we really lack a mechanism for propagating
"operational" or "deployment" experience. IETF/IDR at least was willing to
look at my multihoming draft. I have another document,
tutorial/experienced based in a similar way, that deals with OSPF
deployment methods. But since it's focused on enterprise networks, it
really doesn't seem to fit the inter-carrier operations audiences.

Howard