Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-bgpsecrec-10.txt

From: [email-masked]
Date: Mon, 3 Nov 2008 10:30:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Routing Protocol Security Requirements Working Group of the IETF.

	Title		: BGP Security Requirements
	Author(s)	: B. Christian, T. Tauber
	Filename	: draft-ietf-rpsec-bgpsecrec-10.txt
	Pages		: 18
	Date		: 2008-11-3
	
The security of BGP, the Border Gateway Protocol, is critical to the
   proper operation of large-scale internetworks, both public and
   private.  While securing the information transmitted between two BGP
   speakers is a relatively easy technical matter, securing BGP, as a
   routing system, is more complex.  This document describes a set of
   requirements for securing BGP and the routing information carried
   within BGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
RPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rpsec

---

From: Tony Tauber <[email-masked]>
Date: Sun, 16 Nov 2008 19:54:07 -0800

Hi Folks,

[WG Chair hat off]

The WG is winding down but it'd be nice to just put a stake in this
draft.

Russ, can we move forward with this?

Unfortunately, I won't be in Minneapolis.

Thanks,

Tony

---

From: Russ White <[email-masked]>
Date: Wed, 19 Nov 2008 09:43:53 -0500

> Russ, can we move forward with this?

I don't see why not.... I would say it's time to issue a last call on
this one, and move ahead.

:-)

Russ

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

---

From: Russ White <[email-masked]>
Date: Wed, 19 Nov 2008 09:46:38 -0500

Folks:

This draft has been around a long long time, and has been subject to a
great deal of discussion. I would like to start a two week last call on
this one, at the end of which we'll forward this to the ADs for final
preparations for publication.

Please post any comments to the list.

Thanks!

:-)

Russ

- --

---

From: Geoff Huston <[email-masked]>
Date: Thu, 20 Nov 2008 06:07:12 +1100

SIDR WG co-chair hat ON
Hi Tony,
The draft still contains the text:
o AS_PATH Feasibility Check: The AS_PATH list may correspond to a  
valid list of autonomous systems according to the first verification  
category listed in the "Areas to Secure" Section above. Further study  
will determine the extent to which this is a security requirement.
o Update Transit Check: Routing information carried through BGP may  
include information that can be used to verify the re- advertisement  
or modification by each autonomous system through which the UPDATE has  
passed. This check is more rigorous than the "valid list of autonomous  
systems" above. Further study will determine the extent to which this  
is a security requirement.
SIDR has the chartered role to work on means of implementing those  
security requirements as identified by the RPSEWC working group. The  
charter states: The SIDR working group will develop security  
mechanisms which fulfill those requirements which  have been agreed on  
by the RPSEC working group.

As it stands it is somewhat difficult to figure out what to do about  
AS Path validation given that the text punts on this with a reference  
to "further study. It seems that AS Path validation, in either form,  
is not a agreed requirement from the RPSEC working group. Is this a  
correct interpretation of the situation Tony? Do you have any advice  
you can pass to the SIDR WG on this topic?

regards,

   Geoff
   co-chair SIDR WG

On 20/11/2008, at 1:43 AM, Russ White wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFJJCYpER27sUhU9OQRAh7+AKDf/AUJdl6iknHj9hSenjopWbie6QCg7z98
> +ekbhVfA2yl8GS6Y6unvgo4=
> =8a6b
> -----END PGP SIGNATURE-----

---

From: Geoff Huston <[email-masked]>
Date: Thu, 20 Nov 2008 06:48:33 +1100

Russ,

I'd like to point out that the great deal of discussion you reference  
was on the one topic that is not resolved in this draft. If the  
implication of moving this document on to publication is that this  
protracted discussion has to be replayed from scratch and word for  
word in another working group then I'd say that this was not a useful  
or desireable outcome. Is it really the view of the RPSEC Chairs that  
this is simply unresolveable?

(to be clear, I'm not for or against moving this draft onward as yet,  
but I am trying to understand if I should be!)

   Geoff

On 20/11/2008, at 1:46 AM, Russ White wrote:

> iD8DBQFJJCbOER27sUhU9OQRAuPyAJ9atVsVpZZKU7vef3OYpekRj1akXQCdHqYX
> 3wKIcfUUP6WNAiQizccc4A4=
> =ThSK

---

From: Joe Touch <[email-masked]>
Date: Wed, 19 Nov 2008 12:20:54 -0800

> Please post any comments to the list.

Hi, all,

I have feedback dating back to June 2007 which remains unaddressed. I
repeat it here, as well as adding additional comment from the current
version.

Joe

- --------------------------
- From June 2007:

Abstract - I disagree that securing the info between the parties is an
easy technical matter; if it were, transport or network would be in more
regular use.

This document should note explicitly (e.g., in the abstract or at latest
in Sec 2.3) that network and transport security are not addressed in
this document.

- ---------------------------

This document really should have a section that addresses the
relationship of BGP security to transport and network security. It would
 be useful to point out that BGP interprets transport reachability as
routing reachability - and that this decision renders it particularly
vulnerable to attacks that interrupt the transport layer. This implies
that BGP SHOULD protect its TCP connection, e.g., via IPsec or TCP-AO.

This section should also state that some other issues noted throughout
this document - e.g., DDOS overload protection, processing
considerations, buffering considerations, router configuration,
initialization, key management, etc. - apply to the TCP protection as
well as BGP.

- ---------------------------