Subject: [RPSEC] Situation with BGP security reqs draft

From: Alex Zinin <[email-masked]>
Date: Tue, 25 Jan 2005 18:34:26 -0800

Folks-

 Now that I've caught up on the discussion on the ML, I should say that with
 more people involved within the last 2-3 days, the discussion has gotten much
 healthier and more technical. Clear technical arguments, patience, and mutual
 desire to explain one's point of view is exactly what'd like to happen in this
 WG, considering the difference in background of people showing up here.

 Regarding the topic of securing the AS path. Given the improvement in the
 situation on the mailing list, it seems the WG would benefit from some more
 discussion on this topic, concentrating on the questions whether securing AS
 Path (note that I'm not defining "secure" here) is possible and useful. While
 there's no unanimous agreement on this topic, I've seen a few people say it
 would be interesting to be able to do so, even if there were exceptions to the
 general case. I believe more discussion is warranted.

 I would also like to comment on a few things I observed when following the
 discussion:

  1. My recommendation would be to first converge on terminology. I sense a lot
     of frustration on both routing and security sides triggered by very loose
     use of both routing and security terms. I understand how this can be
     annoying to us, engineers, who prefer precise definitions. I'd start by
     agreeing on what you mean by BGP Route, BGP Update, address space authorization,
     prefix announcement authorization, etc. However, please don't simply say
     "this is not the term we use", try to explain and educate if necessary.
     Someone will also need to maintain the list of agreed on terms.

  2. Regarding whether the discussion and the requirements document should be
     based on the BGP spec vs the operational aspects, and whether operational
     aspects belong here at all or should go to the OPS area. The fact is--we
     need both. It is impossible to secure a protocol without a specification
     that defines a reference model describing its behavior. On the other hand,
     blindly ignoring operational realities simply because they are not described
     in the spec is not the right thing to do. We need security requirements for
     a protocol defined by an IETF spec with the real-life operational
     considerations in mind. The fact that this WG is in the RTG area and not
     in O&M should not stop you from doing that.

     In situations where operational reality differs from the spec, try to use
     common sense. If some operational practice isn't explicitly spelled out,
     but falls within the BGP framework (e.g. route reorigination vs route
     aggregation within BGP), we simply have to deal with it and point out
     the security implications. If the reality contradicts the spec, then it is
     either that the implementation decided to be non-compliant and we shouldn't
     have to deal with it, or the spec needs to be fixed and we need to advise
     the IDR WG.

  3. I noticed people argue that since one can't really guarantee that packet
     forwarding trajectory will follow the routing update trajectory, one
     shouldn't be interested in the routing update trajectory at all. My advice
     would be to limit these discussions to the properties of the protocol
     itself. E.g., I would consider interactions with static routes out of
     control of BGP, and hence out of scope for this discussion.

  I will follow up with Russ, Steve, and Tony more off the list.
  
-- 
Alex
http://www.psg.com/~zinin

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

---

From: Russ White <[email-masked]>
Date: Wed, 26 Jan 2005 00:56:51 -0500 (EST)

>      Someone will also need to maintain the list of agreed on terms.

In order to start this portion of the discussion, I _think_ the two
wordings currently proposed for the meaning of "secure the AS Path" are:

-- Routing information carried through BGP SHOULD include information
   which can be used to verify readvertisement or modification by each
   autonomous system through which the route has passed.

-- A BGP speaker MUST, on receiving a route from a peer, be able to
   verify the AS Path, beginning with the first AS listed in the AS
   Path, progressing through each AS listed in the AS Path, and ending
   in the autonomous system advertising the route to the receiving
   speaker, is a valid route within the internetwork.

(Where valid means the AS Path matches a set of pairwise peering
relationships that can be shown to exist in the internetwork, and the
policy of each AS listed in the path permits the transiting of traffic
through the AS).

-- A BGP speaker MUST, on receiving a route from a peer, be able to
   verify the originating AS has authorization to advertise the prefix
   contained in the route.

[-] OR [-]

-- A BGP speaker MUST, on receiving a route from a peer, be able to
   verify the routing information has passed through every pair wise
   peering relationship listed in the AS Path attribute.

-- A BGP speaker MUST, on receiving a route from a peer, be able to
   verify the originating AS has authorization to advertise the prefix
   contained in the route.

I'm assuming the wording about enforce first AS is included in both cases,
as it is in the current draft.

I've tried to use formal and equivalent language in both definitions. Would
everyone agree these fairly represent the two views being discussed? If you
don't agree, please suggest wording that corrects what you think is wrong
about either definition.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 26 Jan 2005 12:35:54 +0100

<inline>

Tom Petch
----- Original Message -----
From: "Alex Zinin" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, January 26, 2005 3:34 AM
Subject: [RPSEC] Situation with BGP security reqs draft

>      agreeing on what you mean by BGP Route,

Route
      A unit of information that pairs a set of destinations with the
      attributes of a path to those destinations. The set of destina-
      tions are systems whose IP addresses are contained in one IP
      address prefix carried in the Network Layer Reachability Informa-
      tion (NLRI) field of an UPDATE message. The path is the informa-
      tion reported in the path attributes field of the same UPDATE mes-
      sage.

This is taken from the latest revision of the BGP specification and so,
while it may not be the natural definition for other aspects of routing
and routing protocols, I think it is the only one to use in the context
of BGP security.  This definition has been the underlying source of many
discussions on the IDR list ie people assume a route is something else.

---

From: Stefan Mink <[email-masked]>
Date: Wed, 26 Jan 2005 13:45:31 +0100

> wordings currently proposed for the meaning of "secure the AS Path" are:

For me the distinction between the items were too fine
for me to fully get them, so I try my own version:

A "secure AS path" is

a) "authentic":
         It MUST be verifyable who did which change to the
         attribute. This includes "complete": deletion of
         items can be detected and can be made visible.
         (may be this should be generalized to the entire
          route so no special treatment of the as-path
          attribute is necessary)

b) "authorized":
     b1) It MUST be verifyable that the first AS in the path
         was authorized to enter it into the internet routing
         table ("origin authorization")
     b2) It MUST be verifyable that each AS on the path
         was authorized to use the route, i.e. the preceding AS
         intentively announced the route to exactly this AS.
         ("usage authorization")
     b3) It SHOULD be verifyable that each party on the path
         was authorized to readvertise the route to exactly
         the next AS. ("transit authorization")

I'm not sure about the SHOULDs/MUSTs, this is just a first shot.

The SHOULD in the last item is based upon my impression
that there is no proper solution for that so far, e.g.
there are no means currently to prevent a customer from
readvertising your routes although is authorized to
readvertise them to its customers.

I hope this second view helps somewhat, if not:
just forget it ;)

    tschuess
              Stefan Mink
-- 
Stefan Mink, Schlund+Partner AG (AS 8560)
Primary key fingerprint: 389E 5DC9 751F A6EB B974  DC3F 7A1B CF62 F0D4 D2BA
_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 27 Jan 2005 10:25:46 -0500

>    speaker, is a valid route within the internetwork.

I think these cover the points quite well.

>    verify the originating AS has authorization to advertise the prefix

Agreed (caveats on the proxy aggregation case).

>    peering relationship listed in the AS Path attribute.

This MUST is stronger than the SHOULD in your first point cited at
the top of this mail.  Also, that first point cited notes that we want
include  "information which can be used to verify..." whereas this one
cites the AS_PATH.

I personally think the AS_PATH covers much of this capability.  However,
to be clear for the requirements, the "information which can be used
to verify" is closer to what I think we mean.  

Securing the AS_PATH, like securing the other path attributes, will 
likely be a goal, depending on what we mean by securing path attributes.
However, the goal of preventing against man in the middle attacks
is what I think we actually want out of this functionality.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 27 Jan 2005 10:30:33 -0500

>          route so no special treatment of the as-path

I think what you mean here is a form of integrity check.

I'm somewhat concerned from an implementation standpoint that common
changes will make integrity a hard thing to do.  For example, the
deletion of communities.

>         intentively announced the route to exactly this AS.

I agree with this two checks.  I don't think authorized is the right
word here.

>         the next AS. ("transit authorization")

I don't think we want to try to put this into the draft, based on
your clarification message.  This is not currently a feature of BGP.

-- 
Jeff Haas 
NextHop Technologies

---

From: Stefan Mink <[email-masked]>
Date: Thu, 27 Jan 2005 17:55:07 +0100

Hi Jeffrey,

> I think what you mean here is a form of integrity check.

an authenticity check always includes an integrity check, doesn't it?
the difference is, you can not only see that the data is integer,
but also who sent it. Authenticity is always connected to an
identity (name or key).

> changes will make integrity a hard thing to do.  For example, the

definitely! Every deletion/modification of attributes, that is
not somehow reproducable from the data in the attributes, makes
this check impossible. That's one of the reasons why S-BGP is
complex. But without that check, you blindly accept data...

> I agree with this two checks.  I don't think authorized is the right

it's a question: allowed or not? This is usually called
authorization check, but since I'm not a native english speaker,
I'm open to proposals :)

> your clarification message.  This is not currently a feature of BGP.

for me, all authorization checks are outside of BGP, because
BGP itself can't handle them naturally. External data sources
supporting BGP are necessary. I don't see a difference here
between origin authorization (based e.g. on IRR data) and transit
authorization (based on contract data between providers).

On the other side, without authorization checks, _IDR_
can not be secured. We can discuss if these checks are
necessary to secure the _BGP protocol_. I must concede
that I have problems to draw a clear line between these
topics...

    tschuess
              Stefan