Subject: [RPSEC] security considerations - case in point: draft-turk-ertb-00.txt

From: [email-masked]
Date: Mon, 8 Jul 2002 10:18:33 -0400 (EDT)

Perhaps one of the goals of the working group ought to be to provide
guidelines and security requirements so that those who write security
considerations sections can write something more explicit than the
just announced draft-turk-ertb-00.txt, which says:

   It is very important to practice tight control over BGP peering
   points before implementing this technique.  BGP customers might be
   able to compromise a particular piece of the network using the Black
   holing communities.  Making sure that a match for locally generated
   BGP announcement exist helps in limiting the ability to drive a
   network to a null interface to the local AS.  Some other security
   considerations MUST be looked at based on the status of the AS those
   techniques are being implemented at.

The "MUST" for "some other security considerations" particularly caught
my eye.  And then there's the requirement for "tight control".

It seems that people want to do the right thing, they're just at sea
about what that is and how to do it.

--Sandy

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

---

From: Tony Tauber <[email-masked]>
Date: Mon, 8 Jul 2002 11:37:07 -0400 (EDT)

> considerations sections can write something more explicit than the

I agree completely.

Alex posted a decent stab at a framework a couple of months ago:

http://www1.ietf.org/mail-archive/working-groups/rpsec/current/msg00065.html

and I replied at that time:

++> It seems to me that when thinking about security it's often
++> matter of classifying a given situation and then knowing
++> what kinds of questions to ask about such a situation.
++>
++> This way protocol designers, implementors and users can
++> ask "What about DoS?"  "What about authorization?", etc.

Might people want to pick that one up and work with it?

Personally, I can cogitate on security half-decently, but know not
that much about protocol design and what people usually go through
with that.

Tony

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 8 Jul 2002 15:37:30 -0400

> about what that is and how to do it.

In the case of BGP communities and their extended cousins, there was
a nice e-mail from Andrew Partan that summarized a good BCP as to
what one should do inside one's AS to help keep the Internet
community space clean.  Having a standard knob that people can turn
to do this would be a nice thing.

The mail in whole:
: From: Andrew Partan <[email-masked]>
: To: "Martin, Christian" <[email-masked]>
: Cc: [email-masked]
: Subject: Re: BGP TTL
: Precedence: bulk
: X-NextHop-MailScanner: Found to be clean
: X-UIDL: 73b1d38620013b30a92e9b2767474679
:
: On Wed, Mar 20, 2002 at 03:25:23PM -0500, Martin, Christian wrote:
: > Perhaps communities should become mandatory transitive attributes?
:
: That is not a good idea.  You still need to block communities you use
: internally so others can't effect your router.
:
: Ideal provider config is
:         - strip all communities you use for internal markers on input
:         - act on all communities you tell you customers they may use
:         - strip all your communities on output
:         - let all other communities thru untouched
:
:         --asp

The gotcha here being "your communities".

-- 
Jeff Haas 
NextHop Technologies