draft-ietf-ptomaine-nopeer-00.txt

[Geoff Huston]

At 12:48 PM 11/14/2002 -0800, Randy Bush wrote:
>on todday's iesg call, a number of folk were concerned about the
>issues raised in smb's comment below.  i think it is a legitimate
>issue.
>
>randy
>
>---
>
>From: "Steven M. Bellovin" <smb at research.att.com>
>
>The Security Considerations section is a bit scary.  It says, in
>effect, "this makes an existing attack worse".  Do we really want that?
>Absent something like sbgp, one defense is monitoring AS paths to
>important destinations -- this can, to some extent, prevent such
>monitoring.
>
>In a separate vein, routing games are useful adjuncts to eavesdropping
>and MITM attacks (if no crypto us used), not just DoS attacks.  That
>should be clarified.

Randy had already forwarded this comment to me a few days ago,
and my response at the time  went along the following lines:

Obviously I'd be interested in comments from the WG on
wording that can be used in the Security Considerations
section that would address Steve's concerns.

   Geoff

---

My original response

Not quite  - it says "adoption of use of this attribute can allow yet another
form of attack within BGP."  In terms of truth in advertising, yes, I believe
that this statement is an accurate portrayal of the situation.

The next question was "Do we really want that?"

And the ideal response is that no, what we would all want us a more secure
form of operating inter-domain routing that allows others to identify and 
discard
attempts to inject false information.

There are way too many games that can be played in BGP to create all
kinds of havoc, and I'm sure that I can dream up only a small proportion
of the attack vulnerabilities in the eBGP space, and that the true extent
of our vulnerabilities in this area is a sobering thought.

NOPEER is a very small and very modest contribution to the BGP
environment and its motive is to allow operators some additional capability
to limit the propagation of Traffic-Engineering-motivated small prefix
advertisements into the broader eBGP world. The intent is to
assist in limiting massive growth rates in the eBGP space as a
palliative measure to assist in scaling.

The downside is that BGP has no clean way to verify and validate the
information that is being exchanged acorss any arbitrary eBGP session,
and any mechanism to allow an originator to scope the extent of a
route advertisement allows an attacker to scope the extent of
an attack vector.

Now that's a pretty large problem with BGP and this draft does not
pretend that the problem does not exist, nor does it pretend that this
particular attribute assists with BGP verification and validity.

I believe that there is a very real operations / routing / security issue with
BGP as practised today. To what extent we want to focus effort
on this to the exclusion of all other inter-domain routing  activities is
an open question. Adding more knobs and whistles to BGP while we are still
pondering what is required in the security and integrity may not be wise.
Just a few thoughts in any case