Subject: RE: [RPSEC] proposed message to the IESG

From: "Susan Hares" <[email-masked]>
Date: Wed, 26 Jan 2005 12:33:14 -0500

Blaine:

I'm catching up on a 4 days of exciting email.  In reading through the
email, I'd like to make sure I understand this point: 

-----Original Message-----
From: Blaine Christian [mailto:[email-masked]] 
Sent: Thursday, January 20, 2005 5:38 PM
To: Sandy Murphy; Jeffrey Haas
Cc: [email-masked]; [email-masked]
Subject: Re: [RPSEC] proposed message to the IESG

<snip> 

I could not agree more.  BGP has a LOT of wiggle room in it.  This must
make
security oriented folks nuts.  I am only into security operationally.
However, I have quite a bit of background in the "hey your
implementation of
BGP broke me" realm.  Heck, a lot of times it was our specific manner of
implementing BGP that broke people (MED route oscillation due to
confederations comes to mind).  While we will probably not be able to
come
up with a complete requirement that solves everything I do firmly
believe we
can improve the current state of affairs while letting the older
implementations age out gracefully.

<snip> 

1st - Could you comment if the current BGP draft makes this better or
worse? 

2nd - BGP is Path Vector - that is Distance Vector (DV) with a Path.  
	Many of the DV characteristics are "rumor" based protocols -
which by 	nature give the security folks fits.  Can you give a
list of the 
	policy issues you are concerned with? 

Sue

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

---

From: Blaine Christian <[email-masked]>
Date: Wed, 26 Jan 2005 14:52:28 -0500

Just to make it very clear.  Drafts are like armpits, everyone has them and
everyone elses stinks.  There are, at least, two annoying grammatical errors
in the requirements draft for example.  There are also numerous changes that
need to be made (I am trying to keep track of the wonderful arguments and
when phraseology is good I am dropping it in a mail folder for potential
draft insertion).

So, I will point out potential issues with the newest BGP spec draft and I
want everyone to note that the requirements draft is significantly behind in
development when compared to the BGP draft.

I am reading draft-ietf-idr-bgp4-26.txt and basing my comments on it...

> 1st - Could you comment if the current BGP draft makes this better or

Second page, third paragraph, last sentence.

  "BGP can
   support only the policies conforming to the destination-based
   forwarding paradigm."

BGP already does support source-based policies using communities.
Communities have been used to create source based forwarding policy
decisions on two vendors that I know of.  Of course this is more internal
than external but BGP is a rather common tool for internally  propagating
information and the same communities based tools are available across EBGP
sessions by the very nature of the implementation.

BTW, the next sentence says...

" This specification covers only the exchange of IP version 4 network
   reachability information."

Which seems to state that all the other uses for BGP are not covered under
the draft.  Is that true?

Page 6, second paragraph, last sentence.

" The value of the BGP Identifier is determined on startup and is the
      same for every local interface and every BGP peer.
"

Should probably be stated as "The value of the BGP Identifier is determined
on startup and MUST be the same for every local interace and every BGP
peer."  If you want to ensure folks follow the standard <g>.  Saying "is the
same" may be making a rash assumption.

Page 9, paragraph three,

This talks about how an AS is considered a part of the a coherent system to
external AS's.  What stands out, as missing, is reference to confederations,
which each have their own AS and communicate via EIBGP (just a tiny bit
different than EBGP WRT the local decision process and propagation).  I know
Yakov is not fond of confederations anymore but hey... Now we are stuck with
them <grin>.

Page 10, last paragraph,

" If a BGP speaker chooses to advertise a previously received route, it
   MAY add to or modify the path attributes of the route before adver-
   tising it to a peer."

If it is an IBGP peer I can understand not modifying the path attribute.
However, an EBGP peer it MUST modify the path attribute (by prepending it's
own AS) right?  I guess the MAY in this context is confusing.

Page 28, first paragraph,

" A BGP speaker SHALL NOT
   install a route with itself as the next hop."

This comes close to breaking some nifty blackhole routing stuff folks are
doing nowadays.  I think it would still be manageable with communities but
would it be more appropriate to say that a BGP speaker SHALL NOT install a
route received from an EBGP peer with itself as the next hop?   It just may
be a good idea to be careful about breaking the ability to do black hole
routing.  Note the additional language about outbound interfaces that comes
in the paragraph immediately following may need to be revised... We do not
lose this valuable tool (by accident).

Page 29, MEDs,

It is probably a good idea to discourage internal use of MEDs for
implementations that use Route reflectors or confederations.

---Things to add?---

Prefix limits: If both sides of an EBGP session "know" of the prefix limits
it would work a heck of a lot better than to just break a session during a
route table explosion.  An attribute that captures prefix limits could be
communicated between BGP peers.

Strengthen AS insertion language: Only permit AS prepend of your EBGP
neighbor AS inbound and your own AS EBGP outbound?  Just a thought...  I
know of one person who actually wants insert other folks AS's
outbound/inbound.  Most people find it pretty evil to do so.  Perhaps this
can be worked in over time.  Please note that the language in the draft
comes very close to saying this on page 27.

Enforce First AS: If we can solidify this as a BGP security requirement it
should probably go in the BGP spec.  But, then again, a whole lot of stuff
would be slated for insertion.

I ran out of energy and have to get back to work...  I did want you to have
this chunk because I suspect it is going to generate a bit of discussion.

> policy issues you are concerned with?

I love the rumor based bit <g>.  I always envision BGP as leaking puddles of
prefixes.

For me, I am most concerned that I am dealing with the right prefix
advertisement in the first place.  I am sure there are a lot of criteria we
can come up with to take care of this.  I mentioned to the group in one
email that "knowing" that every session along the path had enforce first AS
"on" AND was doing some form of session security would go a long way to
proving the validity of the path.  Combined with a prefix trust mechanism it
seems that we can raise the bar significantly.

With respect to explicit policy:  It is completely within the right of each
operator to manage BGP internal to their network (and distribute/not
distribute prefixes).  It is also completely within the right of the other
peers to ignore their advertisements.  This is where I think we can not
force policy on users.  We have to encourage policy by users.  In other
words, internal to your own network, the choice with what to do about
advertisements is completely yours.  INCLUDING whether the advertisement is
propagated.  If external networks have a better view of your policy they can
make a determination whether they are willing to use your advertisements.

So, a better view of the policies applied would be good.  For example,
knowing about enforce first As and session security seem like policies that
might be good to know about from a route "choice" perspective.

I hope this is meaty enough to stir some more conversation.  Let me know
what you think!

Regards,

Blaine

---

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

<inline>
Tom Petch

----- Original Message -----
From: "Blaine Christian" <[email-masked]>
Sent: Wednesday, January 26, 2005 8:52 PM
Subject: Re: [RPSEC] proposed message to the IESG

> Which seems to state that all the other uses for BGP are not covered under

Yes.

I think this is a key point.  Look hard and you will not find Confederations,
Route Reflectors, VPNs, Communities, IPv6, Route Flap Damping etc etc etc in
this draft, all very valid aspects of BGP.  The aim of this draft does not
include those functions (although the relevant RFC are listed as informative
references with no references in this draft to them:-).

So is BGP security looking at the scope of BGP as defined in this basic document
(give or take some operator licence with prepending or aggregation); or at the
scope of BGP as defined in a much wider set of RFC and I-D?  If the latter,
which documents are included?

---

From: [email-masked]
Date: Thu, 27 Jan 2005 01:19:05 +0000

> which documents are included?

	it would seem best to stay tightly focused on the core spec,
	since new stuff is allowed (and used to be encouraged) to emerge
	to deal w/ changing situations... like the short list above!

---

From: Blaine Christian <[email-masked]>
Date: Thu, 27 Jan 2005 07:54:58 -0500

> to deal w/ changing situations... like the short list above!

I am comfortable with that...  But we have actually left the language in the
requirements doc much more open WRT BGP.  The document actually went under
one revision where it was about inter-domain routing not BGP specifically.

Does anyone have thoughts on wording to the effect that, for the purposes of
the document, we come up with a term that represents a network that could be
comprised of multiple AS's?   I think the new term could reference AS as
it's progenitor but might more accurately characterize the current
environment.  Of specific interest are the private AS space bits since the
private AS space is used internally in many networks.  But it may be worth
reviewing whether a group of public AS numbers would be appropriate to group
together under the "one key one network" thought.

Also, the one "standout" in the list Tom presented was IPv6.  IPv6 is one of
the few, in my opinion, that has odds of being globally transitive like
IPv4.  The rest of the bits mentioned are likely to be local and remain so.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 27 Jan 2005 09:24:57 -0500

> IPv4.  The rest of the bits mentioned are likely to be local and remain so.

The pairing of NLRI with path attributes is still, in both IPv4 and IPv6,
the thing that we're trying to secure.  The one bit of implementation
(and thus solution-specific) based kinkiness is that anything besides
IPv4 unicast reachability (and not always then) is represented as
a field in the path attributes.

Confederations are a possible sticky point when you have more than
one "internal" entity that wants to run secured ebgp in the confederation.
Our requirements shouldn't preclude this.

-- 
Jeff Haas 
NextHop Technologies