Re: slides from IETF idr meeting Mar 19, 2003

[[e-mail]]

>Nov 02 discussion of security, but no presentation
>    (draft-murphy-bgp-protect-01.txt submitted, date change only)

True enough, but more important for this discussion:
     (draft-murphy-bgp-vuln-01.txt submitted, date change only)

--Sandy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24957 for <[e-mail]>; Mon, 31 Mar 2003 11:11:14 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 674D39127F; Mon, 31 Mar 2003 11:10:53 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30F4191280; Mon, 31 Mar 2003 11:10:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18AB29127F for <[e-mail]>; Mon, 31 Mar 2003 11:10:52 -0500 (EST)
Received: by segue.merit.edu (Postfix) id ECAEF5DD94; Mon, 31 Mar 2003 11:10:51 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 793F35DD91 for <[e-mail]>; Mon, 31 Mar 2003 11:10:51 -0500 (EST)
Received: by sentry.gw.tislabs.com; id LAA23973; Mon, 31 Mar 2003 11:11:47 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma023963; Mon, 31 Mar 03 11:11:19 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2VGAMw11595; Mon, 31 Mar 2003 11:10:23 -0500 (EST)
Date: Mon, 31 Mar 2003 11:10:23 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail], [e-mail]
Subject: Re: slides from IETF idr meeting Mar 19, 2003
Sender: [e-mail]
Precedence: bulk

>Nov 02 discussion of security, but no presentation
>    (draft-murphy-bgp-protect-01.txt submitted, date change only)

True enough, but more important for this discussion:
     (draft-murphy-bgp-vuln-01.txt submitted, date change only)

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA24831 for <[e-mail]>; Mon, 31 Mar 2003 10:59:51 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 95C1F91272; Mon, 31 Mar 2003 10:59:25 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6170F9127F; Mon, 31 Mar 2003 10:59:25 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DBDE691272 for <[e-mail]>; Mon, 31 Mar 2003 10:59:23 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C83BB5DD93; Mon, 31 Mar 2003 10:59:23 -0500 (EST)
Delivered-To: [e-mail]
Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by segue.merit.edu (Postfix) with ESMTP id 7E19D5DD8C for <[e-mail]>; Mon, 31 Mar 2003 10:59:23 -0500 (EST)
Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h2VFxp71021972; Mon, 31 Mar 2003 07:59:51 -0800
Date: Mon, 31 Mar 2003 07:59:51 -0800
From: David Meyer <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP protocol analysis
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Mar 31, 2003 at 07:27:50AM -0800
Sender: [e-mail]
Precedence: bulk

Yakov/All,

Comments very welcome. There are quite a few updates to this one
already.

Thanks,

Dave

On Mon, Mar 31, 2003 at 07:27:50AM -0800, Yakov Rekhter wrote:
>> Folks,
>> 
>> Please review and comment on the BGP Protocol Analysis draft.
>> 
>> Yakov.
>> ------- Forwarded Message
>> 
>> Date:    Mon, 24 Mar 2003 07:25:25 -0500
>> From:    [e-mail]
>> To:      IETF-Announce: ;
>> cc:      [e-mail]
>> Subject: I-D ACTION:draft-ietf-idr-bgp-analysis-00.txt
>> 
>> - --NextPart
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Inter-Domain Routing Working Group of the IETF
>> .
>> 
>> 	Title		: BGP-4 Protocol Analysis
>> 	Author(s)	: D. Meyer, K. Patel
>> 	Filename	: draft-ietf-idr-bgp-analysis-00.txt
>> 	Pages		: 15
>> 	Date		: 2003-3-20
>> 	
>> The purpose of this report is to document how the requirements for
>> advancing a routing protocol from Draft Standard to full Standard
>> have been satisfied by Border Gateway Protocol version 4 (BGP-4).
>> This report satisfies the requirement for'the second report', as
>> described in Section 6.0 of RFC 1264 [RFC1264].  In order to fulfill
>> the requirement, this report augments RFC 1774 [RFC1774] and
>> summarizes the key features of BGP protocol, and analyzes the
>> protocol with respect to scaling and performance.
>> 
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-00.txt
>> 
>> To remove yourself from the IETF Announcement list, send a message to 
>> ietf-announce-request with the word unsubscribe in the body of the message.
>> 
>> Internet-Drafts are also available by anonymous FTP. Login with the username
>> "anonymous" and a password of your e-mail address. After logging in,
>> type "cd internet-drafts" and then
>> 	"get draft-ietf-idr-bgp-analysis-00.txt".
>> 
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html 
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> 
>> 
>> Internet-Drafts can also be obtained by e-mail.
>> 
>> Send a message to:
>> 	[e-mail].
>> In the body type:
>> 	"FILE /internet-drafts/draft-ietf-idr-bgp-analysis-00.txt".
>> 	
>> NOTE:	The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>> 		
>> 		
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> 
>> - --NextPart
>> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
>> 
>> - --OtherAccess
>> Content-Type: Message/External-body;
>> 	access-type="mail-server";
>> 	server="[e-mail]"
>> 
>> Content-Type: text/plain
>> Content-ID:	<[e-mail]>
>> 
>> ENCODING mime
>> FILE /internet-drafts/draft-ietf-idr-bgp-analysis-00.txt
>> 
>> - --OtherAccess
>> Content-Type: Message/External-body;
>> 	name="draft-ietf-idr-bgp-analysis-00.txt";
>> 	site="ftp.ietf.org";
>> 	access-type="anon-ftp";
>> 	directory="internet-drafts"
>> 
>> Content-Type: text/plain
>> Content-ID:	<[e-mail]>
>> 
>> - --OtherAccess--
>> 
>> - --NextPart--
>> 
>> 
>> 
>> ------- End of Forwarded Message


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA24601 for <[e-mail]>; Mon, 31 Mar 2003 10:28:13 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E4234912FC; Mon, 31 Mar 2003 10:27:53 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 993A1912FF; Mon, 31 Mar 2003 10:27:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7FBCA912FC for <[e-mail]>; Mon, 31 Mar 2003 10:27:51 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 699005E238; Mon, 31 Mar 2003 10:27:51 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id D3ACB5E260 for <[e-mail]>; Mon, 31 Mar 2003 10:27:50 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2VFRoS62831 for <[e-mail]>; Mon, 31 Mar 2003 07:27:50 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: BGP protocol analysis
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 31 Mar 2003 07:27:50 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

Please review and comment on the BGP Protocol Analysis draft.

Yakov.
------- Forwarded Message

Date:    Mon, 24 Mar 2003 07:25:25 -0500
From:    [e-mail]
To:      IETF-Announce: ;
cc:      [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp-analysis-00.txt

- --NextPart

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

	Title		: BGP-4 Protocol Analysis
	Author(s)	: D. Meyer, K. Patel
	Filename	: draft-ietf-idr-bgp-analysis-00.txt
	Pages		: 15
	Date		: 2003-3-20
	
The purpose of this report is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for'the second report', as
described in Section 6.0 of RFC 1264 [RFC1264].  In order to fulfill
the requirement, this report augments RFC 1774 [RFC1774] and
summarizes the key features of BGP protocol, and analyzes the
protocol with respect to scaling and performance.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp-analysis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-analysis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-analysis-00.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-analysis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

- --OtherAccess--

- --NextPart--



------- End of Forwarded Message



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA24376 for <[e-mail]>; Mon, 31 Mar 2003 10:04:32 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A91109127C; Mon, 31 Mar 2003 10:04:11 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80FCF9127E; Mon, 31 Mar 2003 10:04:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CEE399127C for <[e-mail]>; Mon, 31 Mar 2003 10:02:44 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8D6FB5E1D5; Mon, 31 Mar 2003 10:02:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id D75BB5E140 for <[e-mail]>; Mon, 31 Mar 2003 10:02:06 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA53567; Mon, 31 Mar 2003 10:01:37 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], "Susan Hares" <[e-mail]>, "IDR WG (E-mail)" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Mon, 31 Mar 2003 06:17:04 PST." <[e-mail]> 
Date: Mon, 31 Mar 2003 10:01:37 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Yakov Rekhter writes
:
> Curtis,
> 
> > > >, "Susan Hares" writes:
> > > > 
> > > > Curtis:
> > > > 
> > > > My understanding is that this is an addition
> > > > to the security vulnerabilities document. 
> > > > 
> > > > Is this correct?
> > > > 
> > > > Sue
> > > 
> > > 
> > > We are talking about the security section of the BGP4 internet draft.
> > > 
> > > Curtis
> > 
> > 
> > Maybe I should clarify that.
> > 
> > We all know that TCP in the clear has vulnerabilities.  Use of MD5
> > increases the barrier to exploit these.  If snooping is not possible,
> > MD5 is completely effective in this role.
> > 
> > There is a second set of vulnerabilities having to do with DoS.  An
> > attacker can send traffic faster than the authentication can be run to
> > throw it away.  Packet filtering techniques have been used to reduce
> > the exposure and in some cases eliminate it.
> > 
> > A short description (a bit more than these two paragraphs) may be
> > needed in the BGP4 spec.  If you want I'll write something (Monday).
> 
> May I suggest that the proper place for this would be in the BGP
> Vulnerabilities Analysis document. The base spec already has a
> pointer to that document.
> 
> Yakov.


OK.  I'll send something to Sandy and she can decide what to use or
whether to use it.

Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA23930 for <[e-mail]>; Mon, 31 Mar 2003 09:19:43 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9A36B912BB; Mon, 31 Mar 2003 09:19:22 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67D889127E; Mon, 31 Mar 2003 09:19:22 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C3FEE912BB for <[e-mail]>; Mon, 31 Mar 2003 09:17:58 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 106AF5E2BB; Mon, 31 Mar 2003 09:17:26 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id AEEF95E2BA for <[e-mail]>; Mon, 31 Mar 2003 09:17:25 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2VEH4S58674; Mon, 31 Mar 2003 06:17:12 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: "Susan Hares" <[e-mail]>, "IDR WG (E-mail)" <[e-mail]>
Subject: Re: Issue 19) Security Considerations 
In-Reply-To: Your message of "Sat, 29 Mar 2003 17:14:17 EST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 31 Mar 2003 06:17:04 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Curtis,

> > >, "Susan Hares" writes:
> > > 
> > > Curtis:
> > > 
> > > My understanding is that this is an addition
> > > to the security vulnerabilities document. 
> > > 
> > > Is this correct?
> > > 
> > > Sue
> > 
> > 
> > We are talking about the security section of the BGP4 internet draft.
> > 
> > Curtis
> 
> 
> Maybe I should clarify that.
> 
> We all know that TCP in the clear has vulnerabilities.  Use of MD5
> increases the barrier to exploit these.  If snooping is not possible,
> MD5 is completely effective in this role.
> 
> There is a second set of vulnerabilities having to do with DoS.  An
> attacker can send traffic faster than the authentication can be run to
> throw it away.  Packet filtering techniques have been used to reduce
> the exposure and in some cases eliminate it.
> 
> A short description (a bit more than these two paragraphs) may be
> needed in the BGP4 spec.  If you want I'll write something (Monday).

May I suggest that the proper place for this would be in the BGP
Vulnerabilities Analysis document. The base spec already has a
pointer to that document.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA23186 for <[e-mail]>; Mon, 31 Mar 2003 09:08:00 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6A14B912F9; Mon, 31 Mar 2003 09:07:41 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 33771912FA; Mon, 31 Mar 2003 09:07:41 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF241912F9 for <[e-mail]>; Mon, 31 Mar 2003 09:07:39 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D32755E288; Mon, 31 Mar 2003 09:07:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 502725E286 for <[e-mail]>; Mon, 31 Mar 2003 09:07:39 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2VE7WS58233; Mon, 31 Mar 2003 06:07:32 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: Alex Zinin <[e-mail]>, [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-Reply-To: Your message of "Mon, 24 Mar 2003 20:03:47 EST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 31 Mar 2003 06:07:32 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Mon, Mar 24, 2003 at 04:43:57PM -0800, Alex Zinin wrote:
> > Maybe we should change the text to say
> > 
> >  "Implementations MUST support TCP MD5 [RFC2385] for authentication."
> 
> And there would be much rejoicing (as Jeff shuts up).

Done.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA06497 for <[e-mail]>; Sat, 29 Mar 2003 17:15:34 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 10F5F91232; Sat, 29 Mar 2003 17:15:04 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8556B91233; Sat, 29 Mar 2003 17:15:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A9CF891232 for <[e-mail]>; Sat, 29 Mar 2003 17:15:00 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 810675DFB8; Sat, 29 Mar 2003 17:15:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 393535DFB7 for <[e-mail]>; Sat, 29 Mar 2003 17:14:59 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id RAA49861; Sat, 29 Mar 2003 17:14:17 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: "Susan Hares" <[e-mail]>, "Joris Dobbelsteen" <[e-mail]>, "IDR WG (E-mail)" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Sat, 29 Mar 2003 15:56:16 EST." <[e-mail]> 
Date: Sat, 29 Mar 2003 17:14:17 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Curtis Villamizar 
writes:
> 
> In message <[e-mail].
> co
> m>, "Susan Hares" writes:
> > 
> > Curtis:
> > 
> > My understanding is that this is an addition
> > to the security vulnerabilities document. 
> > 
> > Is this correct?
> > 
> > Sue
> 
> 
> We are talking about the security section of the BGP4 internet draft.
> 
> Curtis


Maybe I should clarify that.

We all know that TCP in the clear has vulnerabilities.  Use of MD5
increases the barrier to exploit these.  If snooping is not possible,
MD5 is completely effective in this role.

There is a second set of vulnerabilities having to do with DoS.  An
attacker can send traffic faster than the authentication can be run to
throw it away.  Packet filtering techniques have been used to reduce
the exposure and in some cases eliminate it.

A short description (a bit more than these two paragraphs) may be
needed in the BGP4 spec.  If you want I'll write something (Monday).

Curtis


> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[e-mail]]
> > Sent: Thursday, March 27, 2003 12:52 PM
> > To: Joris Dobbelsteen
> > Cc: IDR WG (E-mail)
> > Subject: Re: Issue 19) Security Considerations 
> > 
> > 
> > 
> > In message <000401c2f439$7cc69ee0$[e-mail]>, "Joris Dobbelste
> en
> > " 
> > writes:
> > > Indeed, for recommendation, TCP-MD5 would be at least a
> > > sufficient minimum, because it is widely implemented.
> > > 
> > > Still it should mention what vulnerabilities are kept open
> > > even when using TCP-MD5, so they can be taken into account
> > > in the future and in current deployments...
> > > 
> > > - Joris
> > 
> > 
> > That's fair.  Name those vulnerabilities and how they apply to use of
> > TCP MD5 for BGP where snooping is generally not possible and we'll put
> > them in.
> > 
> > It might also be worth mentioning the DoS issues, the use of filtering
> > to solve these problems, and the inability to do that filtering with
> > security protocols which hide the port numbers.
> > 
> > If we decide to do this any of a number of people could supply the
> > latter but I'd be willing to.
> > 
> > Curtis
> > 
> > 
> > > >-----Original Message-----
> > > >From: [e-mail] [mailto:[e-mail]]On Behalf Of
> > > >Curtis Villamizar
> > > >Sent: Thursday, 27 March 2003 1:45
> > > >To: John Leslie
> > > >Cc: Curtis Villamizar; Alex Zinin; [e-mail]
> > > >Subject: Re: Issue 19) Security Considerations 
> > > >
> > > >
> > > >
> > > >In message <20030325205614.A1596@verdi>, John Leslie writes:
> > > >>  
> > > >>    I'm not at all wedded to the words I proposed, but if we 
> > > >can't find
> > > >> somewhere in this document to say that TCP-MD5 "should" be 
> > > >used, I think
> > > >> we have no business saying it "must" be implemented.
> > > >
> > > >We don't need that in the protocol spec.  Protocol specs are not
> > > >supposed to dictate usage.  This keeps them simpler.  Usage
> > > >recommendations and implementation experience is provided in separate
> > > >documents, not in the protocol spec.
> > > >
> > > >>    If, instead, we claim that it's entirely up to administrators
> > > >> whether to use TCP-MD5, and we have no recommendation, I 
> > > >don't see how
> > > >> we justify denying them access to implementations which don't include
> > > >> TCP-MD5.
> > > >
> > > >Putting something into a spec doesn't deny access to anything.  By
> > > >mandating TCP MD5 in the security section we just indicate that
> > > >implementations without it have a very severe deficiency with regard
> > > >to meeting security requirements in a way that interoperates with the
> > > >existing installed base.
> > > >
> > > >Curtis
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA03821 for <[e-mail]>; Sat, 29 Mar 2003 15:58:14 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 0FDDA9122F; Sat, 29 Mar 2003 15:57:55 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBD7E91231; Sat, 29 Mar 2003 15:57:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 643159122F for <[e-mail]>; Sat, 29 Mar 2003 15:57:53 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 45A4B5DFA9; Sat, 29 Mar 2003 15:57:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 20B365DFA6 for <[e-mail]>; Sat, 29 Mar 2003 15:57:52 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA49521; Sat, 29 Mar 2003 15:56:16 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Susan Hares" <[e-mail]>
Cc: [e-mail], "Joris Dobbelsteen" <[e-mail]>, "IDR WG (E-mail)" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Fri, 28 Mar 2003 08:42:49 EST." <[e-mail]> 
Date: Sat, 29 Mar 2003 15:56:16 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
m>, "Susan Hares" writes:
> 
> Curtis:
> 
> My understanding is that this is an addition
> to the security vulnerabilities document. 
> 
> Is this correct?
> 
> Sue


We are talking about the security section of the BGP4 internet draft.

Curtis


> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Thursday, March 27, 2003 12:52 PM
> To: Joris Dobbelsteen
> Cc: IDR WG (E-mail)
> Subject: Re: Issue 19) Security Considerations 
> 
> 
> 
> In message <000401c2f439$7cc69ee0$[e-mail]>, "Joris Dobbelsteen
> " 
> writes:
> > Indeed, for recommendation, TCP-MD5 would be at least a
> > sufficient minimum, because it is widely implemented.
> > 
> > Still it should mention what vulnerabilities are kept open
> > even when using TCP-MD5, so they can be taken into account
> > in the future and in current deployments...
> > 
> > - Joris
> 
> 
> That's fair.  Name those vulnerabilities and how they apply to use of
> TCP MD5 for BGP where snooping is generally not possible and we'll put
> them in.
> 
> It might also be worth mentioning the DoS issues, the use of filtering
> to solve these problems, and the inability to do that filtering with
> security protocols which hide the port numbers.
> 
> If we decide to do this any of a number of people could supply the
> latter but I'd be willing to.
> 
> Curtis
> 
> 
> > >-----Original Message-----
> > >From: [e-mail] [mailto:[e-mail]]On Behalf Of
> > >Curtis Villamizar
> > >Sent: Thursday, 27 March 2003 1:45
> > >To: John Leslie
> > >Cc: Curtis Villamizar; Alex Zinin; [e-mail]
> > >Subject: Re: Issue 19) Security Considerations 
> > >
> > >
> > >
> > >In message <20030325205614.A1596@verdi>, John Leslie writes:
> > >>  
> > >>    I'm not at all wedded to the words I proposed, but if we 
> > >can't find
> > >> somewhere in this document to say that TCP-MD5 "should" be 
> > >used, I think
> > >> we have no business saying it "must" be implemented.
> > >
> > >We don't need that in the protocol spec.  Protocol specs are not
> > >supposed to dictate usage.  This keeps them simpler.  Usage
> > >recommendations and implementation experience is provided in separate
> > >documents, not in the protocol spec.
> > >
> > >>    If, instead, we claim that it's entirely up to administrators
> > >> whether to use TCP-MD5, and we have no recommendation, I 
> > >don't see how
> > >> we justify denying them access to implementations which don't include
> > >> TCP-MD5.
> > >
> > >Putting something into a spec doesn't deny access to anything.  By
> > >mandating TCP MD5 in the security section we just indicate that
> > >implementations without it have a very severe deficiency with regard
> > >to meeting security requirements in a way that interoperates with the
> > >existing installed base.
> > >
> > >Curtis
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA24975 for <[e-mail]>; Fri, 28 Mar 2003 09:30:11 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 33ED7912C3; Fri, 28 Mar 2003 09:29:45 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05507912C4; Fri, 28 Mar 2003 09:29:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98813912C3 for <[e-mail]>; Fri, 28 Mar 2003 09:29:43 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 7D75D5DDB4; Fri, 28 Mar 2003 09:29:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 312935DDB2 for <[e-mail]>; Fri, 28 Mar 2003 09:29:42 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2SETfjO018578 for [e-mail]; Fri, 28 Mar 2003 09:29:41 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2SETZ9c018541 for <[e-mail]>; Fri, 28 Mar 2003 09:29:35 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: Issue 19) Security Considerations
Date: Fri, 28 Mar 2003 09:29:30 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Issue 19) Security Considerations
Thread-Index: AcL1LlZnu/CzmrVTS9is+UzmA3/Y7QAAG1PA
From: "Susan Hares" <[e-mail]>
To: "Joris Dobbelsteen" <[e-mail]>, "IDR WG (E-mail)" <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id JAA24975

Joris and Eric:
	
	I'll ping Sandy and the IETF editor to push the draft:

http://www.ietf.org/internet-drafts/draft-murphy-bgp-vuln-02.txt

into an IDR draft. 

	As we mentioned at the IDR meeting, the securities considerations
section is in this draft.  Could I enlist you both in the review
and refinement of this document?

Sue

-----Original Message-----
From: Joris Dobbelsteen [mailto:[e-mail]]
Sent: Friday, March 28, 2003 8:30 AM
To: 'IDR WG (E-mail)'
Subject: RE: Issue 19) Security Considerations


Eric,

I would agree on it as it is, just a minor opinion:

The BGP draft might at:
 Security Considerations
   The authentication mechanism that an implementation
   of BGP MUST support is specified in [RFC2385]. The
   authentication provided by this mechanism could be
   done on a per peer basis.

emphasize this only provide minimal security.
"In cases where a BGP implementation accepts connections
from unconfigured hosts, the use of IPSEC AH would couter
these threats as well as replay attacks and would permit
key agreement and roll-over.  If routing data confiden-
tiality were desired, IPSEC ESP would provide that service."
[draft-murphy-bgp-vuln-02.txt]

VERY minor notice to the vuln-draft:
IPSec ESP would effectively defeat packet filters, as this
hides port numbers.


- Joris


>-----Original Message-----
>From: Eric Gray [mailto:[e-mail]]
>Sent: Thursday, 27 March 2003 13:02
>To: Joris Dobbelsteen
>Cc: IDR WG (E-mail)
>Subject: Re: Issue 19) Security Considerations
>
>
>Joris,
>
>    Discussion of security vulnerabilities in routing 
>protocols is the subject
>of another RFC-in-progress -
>
>    "BGP Security Vulnerabilities Analysis", Sandra Murphy, 03/03
>    http://www.ietf.org/internet-drafts/draft-murphy-bgp-vuln-02.txt
>
>This work is what the last reference in the "current" BGP 
>draft is meant
>to refer to.
>
>(Susan - can you fix this reference either by getting Sandy's 
>draft posted
>as an IDR working group draft, or by correcting it in the BGP draft?)
>
>The Security Considerations section - in turn - points to this 
>reference.
>The possibility of explicit inclusion of this work in progress 
>in the draft
>has been discussed to death previously.
>
>What more do we need to do?
>
>--
>Eric Gray
>
>Joris Dobbelsteen wrote:
>
>> Indeed, for recommendation, TCP-MD5 would be at least a
>> sufficient minimum, because it is widely implemented.
>>
>> Still it should mention what vulnerabilities are kept open
>> even when using TCP-MD5, so they can be taken into account
>> in the future and in current deployments...
>>
>> - Joris
>>
>> >-----Original Message-----
>> >From: [e-mail] [mailto:[e-mail]]On Behalf Of
>> >Curtis Villamizar
>> >Sent: Thursday, 27 March 2003 1:45
>> >To: John Leslie
>> >Cc: Curtis Villamizar; Alex Zinin; [e-mail]
>> >Subject: Re: Issue 19) Security Considerations
>> >
>> >
>> >
>> >In message <20030325205614.A1596@verdi>, John Leslie writes:
>> >>
>> >>    I'm not at all wedded to the words I proposed, but if we
>> >can't find
>> >> somewhere in this document to say that TCP-MD5 "should" be
>> >used, I think
>> >> we have no business saying it "must" be implemented.
>> >
>> >We don't need that in the protocol spec.  Protocol specs are not
>> >supposed to dictate usage.  This keeps them simpler.  Usage
>> >recommendations and implementation experience is provided 
>in separate
>> >documents, not in the protocol spec.
>> >
>> >>    If, instead, we claim that it's entirely up to administrators
>> >> whether to use TCP-MD5, and we have no recommendation, I
>> >don't see how
>> >> we justify denying them access to implementations which 
>don't include
>> >> TCP-MD5.
>> >
>> >Putting something into a spec doesn't deny access to anything.  By
>> >mandating TCP MD5 in the security section we just indicate that
>> >implementations without it have a very severe deficiency with regard
>> >to meeting security requirements in a way that 
>interoperates with the
>> >existing installed base.
>> >
>> >Curtis
>> >
>
>
>


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA23635 for <[e-mail]>; Fri, 28 Mar 2003 08:43:22 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 0FC3A912C0; Fri, 28 Mar 2003 08:43:04 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D342F912C1; Fri, 28 Mar 2003 08:43:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4BBBA912C0 for <[e-mail]>; Fri, 28 Mar 2003 08:43:02 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 2A01B5DDA2; Fri, 28 Mar 2003 08:43:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 81CC55DD92 for <[e-mail]>; Fri, 28 Mar 2003 08:43:01 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2SDh0s3017790 for [e-mail]; Fri, 28 Mar 2003 08:43:00 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2SDgs9c017776 for <[e-mail]>; Fri, 28 Mar 2003 08:42:54 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: Issue 19) Security Considerations 
Date: Fri, 28 Mar 2003 08:42:49 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Issue 19) Security Considerations 
Thread-Index: AcL0ihr/Vk+Lvqb4TiqAUs/h+u4sAgApYxPA
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>, "Joris Dobbelsteen" <[e-mail]>
Cc: "IDR WG (E-mail)" <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id IAA23635

Curtis:

My understanding is that this is an addition
to the security vulnerabilities document. 

Is this correct?

Sue


-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]]
Sent: Thursday, March 27, 2003 12:52 PM
To: Joris Dobbelsteen
Cc: IDR WG (E-mail)
Subject: Re: Issue 19) Security Considerations 



In message <000401c2f439$7cc69ee0$[e-mail]>, "Joris Dobbelsteen" 
writes:
> Indeed, for recommendation, TCP-MD5 would be at least a
> sufficient minimum, because it is widely implemented.
> 
> Still it should mention what vulnerabilities are kept open
> even when using TCP-MD5, so they can be taken into account
> in the future and in current deployments...
> 
> - Joris


That's fair.  Name those vulnerabilities and how they apply to use of
TCP MD5 for BGP where snooping is generally not possible and we'll put
them in.

It might also be worth mentioning the DoS issues, the use of filtering
to solve these problems, and the inability to do that filtering with
security protocols which hide the port numbers.

If we decide to do this any of a number of people could supply the
latter but I'd be willing to.

Curtis


> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]]On Behalf Of
> >Curtis Villamizar
> >Sent: Thursday, 27 March 2003 1:45
> >To: John Leslie
> >Cc: Curtis Villamizar; Alex Zinin; [e-mail]
> >Subject: Re: Issue 19) Security Considerations 
> >
> >
> >
> >In message <20030325205614.A1596@verdi>, John Leslie writes:
> >>  
> >>    I'm not at all wedded to the words I proposed, but if we 
> >can't find
> >> somewhere in this document to say that TCP-MD5 "should" be 
> >used, I think
> >> we have no business saying it "must" be implemented.
> >
> >We don't need that in the protocol spec.  Protocol specs are not
> >supposed to dictate usage.  This keeps them simpler.  Usage
> >recommendations and implementation experience is provided in separate
> >documents, not in the protocol spec.
> >
> >>    If, instead, we claim that it's entirely up to administrators
> >> whether to use TCP-MD5, and we have no recommendation, I 
> >don't see how
> >> we justify denying them access to implementations which don't include
> >> TCP-MD5.
> >
> >Putting something into a spec doesn't deny access to anything.  By
> >mandating TCP MD5 in the security section we just indicate that
> >implementations without it have a very severe deficiency with regard
> >to meeting security requirements in a way that interoperates with the
> >existing installed base.
> >
> >Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA23336 for <[e-mail]>; Fri, 28 Mar 2003 08:33:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id C4EF5912BF; Fri, 28 Mar 2003 08:33:29 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C6D3912C0; Fri, 28 Mar 2003 08:33:29 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 54172912BF for <[e-mail]>; Fri, 28 Mar 2003 08:32:40 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 323315DECF; Fri, 28 Mar 2003 08:32:40 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id A41FF5DE79 for <[e-mail]>; Fri, 28 Mar 2003 08:32:39 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2SDWcQR017651 for [e-mail]; Fri, 28 Mar 2003 08:32:38 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2SDWW9c017637 for <[e-mail]>; Fri, 28 Mar 2003 08:32:32 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: Issue 19) Security Considerations 
Date: Fri, 28 Mar 2003 08:32:27 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Issue 19) Security Considerations 
Thread-Index: AcL0OX3iFNpUnqcsTg+iPa7roG1GqgA9EFWw
From: "Susan Hares" <[e-mail]>
To: "Joris Dobbelsteen" <[e-mail]>, "IDR WG (E-mail)" <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id IAA23336

Joris:

	I'm glad you are interested in the BGP 
vulnerabilities.  We can pick up this discussion on
the BGP vulnerabilities draft by Sandy Murphy.

	Mechanisms are specified in the BGP draft, and
we pulled the security section out to become a full
draft.  Could I enlist you as a review of that draft? 

Sue Hares

-----Original Message-----
From: Joris Dobbelsteen [mailto:[e-mail]]
Sent: Thursday, March 27, 2003 3:19 AM
To: IDR WG (E-mail)
Subject: RE: Issue 19) Security Considerations 


Indeed, for recommendation, TCP-MD5 would be at least a
sufficient minimum, because it is widely implemented.

Still it should mention what vulnerabilities are kept open
even when using TCP-MD5, so they can be taken into account
in the future and in current deployments...

- Joris

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]On Behalf Of
>Curtis Villamizar
>Sent: Thursday, 27 March 2003 1:45
>To: John Leslie
>Cc: Curtis Villamizar; Alex Zinin; [e-mail]
>Subject: Re: Issue 19) Security Considerations 
>
>
>
>In message <20030325205614.A1596@verdi>, John Leslie writes:
>>  
>>    I'm not at all wedded to the words I proposed, but if we 
>can't find
>> somewhere in this document to say that TCP-MD5 "should" be 
>used, I think
>> we have no business saying it "must" be implemented.
>
>We don't need that in the protocol spec.  Protocol specs are not
>supposed to dictate usage.  This keeps them simpler.  Usage
>recommendations and implementation experience is provided in separate
>documents, not in the protocol spec.
>
>>    If, instead, we claim that it's entirely up to administrators
>> whether to use TCP-MD5, and we have no recommendation, I 
>don't see how
>> we justify denying them access to implementations which don't include
>> TCP-MD5.
>
>Putting something into a spec doesn't deny access to anything.  By
>mandating TCP MD5 in the security section we just indicate that
>implementations without it have a very severe deficiency with regard
>to meeting security requirements in a way that interoperates with the
>existing installed base.
>
>Curtis
>


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA23275 for <[e-mail]>; Fri, 28 Mar 2003 08:31:41 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D5EAC912BC; Fri, 28 Mar 2003 08:30:27 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F0FB912BF; Fri, 28 Mar 2003 08:30:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40628912BC for <[e-mail]>; Fri, 28 Mar 2003 08:30:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6CE3E5DEDF; Fri, 28 Mar 2003 08:30:25 -0500 (EST)
Delivered-To: [e-mail]
Received: from cmailENV1.svr.pol.co.uk (cmailENV1.svr.pol.co.uk [213.218.77.53]) by segue.merit.edu (Postfix) with ESMTP id B5D2B5DEDD for <[e-mail]>; Fri, 28 Mar 2003 08:30:23 -0500 (EST)
Received: from [62.21.131.43] (helo=xtreme) by cmailENV1.svr.pol.co.uk with smtp (Exim 3.35 #1) id 18ytw5-0007q1-00 for [e-mail]; Fri, 28 Mar 2003 13:30:22 +0000
From: "Joris Dobbelsteen" <[e-mail]>
To: "'IDR WG (E-mail)'" <[e-mail]>
Subject: RE: Issue 19) Security Considerations
Date: Fri, 28 Mar 2003 14:30:05 +0100
Message-ID: <001b01c2f52e$48505480$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

Eric,

I would agree on it as it is, just a minor opinion:

The BGP draft might at:
 Security Considerations
   The authentication mechanism that an implementation
   of BGP MUST support is specified in [RFC2385]. The
   authentication provided by this mechanism could be
   done on a per peer basis.

emphasize this only provide minimal security.
"In cases where a BGP implementation accepts connections
from unconfigured hosts, the use of IPSEC AH would couter
these threats as well as replay attacks and would permit
key agreement and roll-over.  If routing data confiden-
tiality were desired, IPSEC ESP would provide that service."
[draft-murphy-bgp-vuln-02.txt]

VERY minor notice to the vuln-draft:
IPSec ESP would effectively defeat packet filters, as this
hides port numbers.


- Joris


>-----Original Message-----
>From: Eric Gray [mailto:[e-mail]]
>Sent: Thursday, 27 March 2003 13:02
>To: Joris Dobbelsteen
>Cc: IDR WG (E-mail)
>Subject: Re: Issue 19) Security Considerations
>
>
>Joris,
>
>    Discussion of security vulnerabilities in routing 
>protocols is the subject
>of another RFC-in-progress -
>
>    "BGP Security Vulnerabilities Analysis", Sandra Murphy, 03/03
>    http://www.ietf.org/internet-drafts/draft-murphy-bgp-vuln-02.txt
>
>This work is what the last reference in the "current" BGP 
>draft is meant
>to refer to.
>
>(Susan - can you fix this reference either by getting Sandy's 
>draft posted
>as an IDR working group draft, or by correcting it in the BGP draft?)
>
>The Security Considerations section - in turn - points to this 
>reference.
>The possibility of explicit inclusion of this work in progress 
>in the draft
>has been discussed to death previously.
>
>What more do we need to do?
>
>--
>Eric Gray
>
>Joris Dobbelsteen wrote:
>
>> Indeed, for recommendation, TCP-MD5 would be at least a
>> sufficient minimum, because it is widely implemented.
>>
>> Still it should mention what vulnerabilities are kept open
>> even when using TCP-MD5, so they can be taken into account
>> in the future and in current deployments...
>>
>> - Joris
>>
>> >-----Original Message-----
>> >From: [e-mail] [mailto:[e-mail]]On Behalf Of
>> >Curtis Villamizar
>> >Sent: Thursday, 27 March 2003 1:45
>> >To: John Leslie
>> >Cc: Curtis Villamizar; Alex Zinin; [e-mail]
>> >Subject: Re: Issue 19) Security Considerations
>> >
>> >
>> >
>> >In message <20030325205614.A1596@verdi>, John Leslie writes:
>> >>
>> >>    I'm not at all wedded to the words I proposed, but if we
>> >can't find
>> >> somewhere in this document to say that TCP-MD5 "should" be
>> >used, I think
>> >> we have no business saying it "must" be implemented.
>> >
>> >We don't need that in the protocol spec.  Protocol specs are not
>> >supposed to dictate usage.  This keeps them simpler.  Usage
>> >recommendations and implementation experience is provided 
>in separate
>> >documents, not in the protocol spec.
>> >
>> >>    If, instead, we claim that it's entirely up to administrators
>> >> whether to use TCP-MD5, and we have no recommendation, I
>> >don't see how
>> >> we justify denying them access to implementations which 
>don't include
>> >> TCP-MD5.
>> >
>> >Putting something into a spec doesn't deny access to anything.  By
>> >mandating TCP MD5 in the security section we just indicate that
>> >implementations without it have a very severe deficiency with regard
>> >to meeting security requirements in a way that 
>interoperates with the
>> >existing installed base.
>> >
>> >Curtis
>> >
>
>
>


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA13122 for <[e-mail]>; Thu, 27 Mar 2003 12:55:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id F35D991205; Thu, 27 Mar 2003 12:55:28 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCDB191206; Thu, 27 Mar 2003 12:55:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77CD491205 for <[e-mail]>; Thu, 27 Mar 2003 12:55:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 688005DDDB; Thu, 27 Mar 2003 12:54:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (unknown [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 1AEDA5DD8E for <[e-mail]>; Thu, 27 Mar 2003 12:54:34 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA37495; Thu, 27 Mar 2003 12:52:19 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Joris Dobbelsteen" <[e-mail]>
Cc: "IDR WG (E-mail)" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Thu, 27 Mar 2003 09:18:45 +0100." <000401c2f439$7cc69ee0$[e-mail]> 
Date: Thu, 27 Mar 2003 12:52:19 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <000401c2f439$7cc69ee0$[e-mail]>, "Joris Dobbelsteen" 
writes:
> Indeed, for recommendation, TCP-MD5 would be at least a
> sufficient minimum, because it is widely implemented.
> 
> Still it should mention what vulnerabilities are kept open
> even when using TCP-MD5, so they can be taken into account
> in the future and in current deployments...
> 
> - Joris


That's fair.  Name those vulnerabilities and how they apply to use of
TCP MD5 for BGP where snooping is generally not possible and we'll put
them in.

It might also be worth mentioning the DoS issues, the use of filtering
to solve these problems, and the inability to do that filtering with
security protocols which hide the port numbers.

If we decide to do this any of a number of people could supply the
latter but I'd be willing to.

Curtis


> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]]On Behalf Of
> >Curtis Villamizar
> >Sent: Thursday, 27 March 2003 1:45
> >To: John Leslie
> >Cc: Curtis Villamizar; Alex Zinin; [e-mail]
> >Subject: Re: Issue 19) Security Considerations 
> >
> >
> >
> >In message <20030325205614.A1596@verdi>, John Leslie writes:
> >>  
> >>    I'm not at all wedded to the words I proposed, but if we 
> >can't find
> >> somewhere in this document to say that TCP-MD5 "should" be 
> >used, I think
> >> we have no business saying it "must" be implemented.
> >
> >We don't need that in the protocol spec.  Protocol specs are not
> >supposed to dictate usage.  This keeps them simpler.  Usage
> >recommendations and implementation experience is provided in separate
> >documents, not in the protocol spec.
> >
> >>    If, instead, we claim that it's entirely up to administrators
> >> whether to use TCP-MD5, and we have no recommendation, I 
> >don't see how
> >> we justify denying them access to implementations which don't include
> >> TCP-MD5.
> >
> >Putting something into a spec doesn't deny access to anything.  By
> >mandating TCP MD5 in the security section we just indicate that
> >implementations without it have a very severe deficiency with regard
> >to meeting security requirements in a way that interoperates with the
> >existing installed base.
> >
> >Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA23443 for <[e-mail]>; Thu, 27 Mar 2003 03:18:59 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B6715912AE; Thu, 27 Mar 2003 03:18:22 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77D71912AF; Thu, 27 Mar 2003 03:18:22 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B86C8912AE for <[e-mail]>; Thu, 27 Mar 2003 03:18:15 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 958175DDBD; Thu, 27 Mar 2003 03:18:15 -0500 (EST)
Delivered-To: [e-mail]
Received: from cmailENV1.svr.pol.co.uk (cmailENV1.svr.pol.co.uk [213.218.77.53]) by segue.merit.edu (Postfix) with ESMTP id 549DE5DDB0 for <[e-mail]>; Thu, 27 Mar 2003 03:18:15 -0500 (EST)
Received: from [62.21.146.42] (helo=xtreme) by cmailENV1.svr.pol.co.uk with smtp (Exim 3.35 #1) id 18ySaR-0008NM-00 for [e-mail]; Thu, 27 Mar 2003 08:18:11 +0000
From: "Joris Dobbelsteen" <[e-mail]>
To: "IDR WG (E-mail)" <[e-mail]>
Subject: RE: Issue 19) Security Considerations 
Date: Thu, 27 Mar 2003 09:18:45 +0100
Message-ID: <000401c2f439$7cc69ee0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

Indeed, for recommendation, TCP-MD5 would be at least a
sufficient minimum, because it is widely implemented.

Still it should mention what vulnerabilities are kept open
even when using TCP-MD5, so they can be taken into account
in the future and in current deployments...

- Joris

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]On Behalf Of
>Curtis Villamizar
>Sent: Thursday, 27 March 2003 1:45
>To: John Leslie
>Cc: Curtis Villamizar; Alex Zinin; [e-mail]
>Subject: Re: Issue 19) Security Considerations 
>
>
>
>In message <20030325205614.A1596@verdi>, John Leslie writes:
>>  
>>    I'm not at all wedded to the words I proposed, but if we 
>can't find
>> somewhere in this document to say that TCP-MD5 "should" be 
>used, I think
>> we have no business saying it "must" be implemented.
>
>We don't need that in the protocol spec.  Protocol specs are not
>supposed to dictate usage.  This keeps them simpler.  Usage
>recommendations and implementation experience is provided in separate
>documents, not in the protocol spec.
>
>>    If, instead, we claim that it's entirely up to administrators
>> whether to use TCP-MD5, and we have no recommendation, I 
>don't see how
>> we justify denying them access to implementations which don't include
>> TCP-MD5.
>
>Putting something into a spec doesn't deny access to anything.  By
>mandating TCP MD5 in the security section we just indicate that
>implementations without it have a very severe deficiency with regard
>to meeting security requirements in a way that interoperates with the
>existing installed base.
>
>Curtis
>


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA07512 for <[e-mail]>; Wed, 26 Mar 2003 19:45:11 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 45E64912A9; Wed, 26 Mar 2003 19:44:44 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F4C3912AB; Wed, 26 Mar 2003 19:44:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BAB6D912A9 for <[e-mail]>; Wed, 26 Mar 2003 19:44:42 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9880F5E267; Wed, 26 Mar 2003 19:44:42 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id BEE4B5DE87 for <[e-mail]>; Wed, 26 Mar 2003 19:44:41 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id TAA34579; Wed, 26 Mar 2003 19:45:16 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: John Leslie <[e-mail]>
Cc: Curtis Villamizar <[e-mail]>, Alex Zinin <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Tue, 25 Mar 2003 20:56:14 EST." <20030325205614.A1596@verdi> 
Date: Wed, 26 Mar 2003 19:45:16 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <20030325205614.A1596@verdi>, John Leslie writes:
>  
>    I'm not at all wedded to the words I proposed, but if we can't find
> somewhere in this document to say that TCP-MD5 "should" be used, I think
> we have no business saying it "must" be implemented.

We don't need that in the protocol spec.  Protocol specs are not
supposed to dictate usage.  This keeps them simpler.  Usage
recommendations and implementation experience is provided in separate
documents, not in the protocol spec.

>    If, instead, we claim that it's entirely up to administrators
> whether to use TCP-MD5, and we have no recommendation, I don't see how
> we justify denying them access to implementations which don't include
> TCP-MD5.

Putting something into a spec doesn't deny access to anything.  By
mandating TCP MD5 in the security section we just indicate that
implementations without it have a very severe deficiency with regard
to meeting security requirements in a way that interoperates with the
existing installed base.

Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA01341 for <[e-mail]>; Wed, 26 Mar 2003 16:51:13 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BCC59912A2; Wed, 26 Mar 2003 16:50:55 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9278A912A3; Wed, 26 Mar 2003 16:50:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5BE56912A2 for <[e-mail]>; Wed, 26 Mar 2003 16:50:54 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 479F65E084; Wed, 26 Mar 2003 16:50:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 7CA465DDC8 for <[e-mail]>; Wed, 26 Mar 2003 16:50:53 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA32228; Wed, 26 Mar 2003 16:51:30 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Joris Dobbelsteen" <[e-mail]>
Cc: "IDR WG (E-mail)" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Wed, 26 Mar 2003 14:37:25 +0100." <001c01c2f3a0$bedf0900$[e-mail]> 
Date: Wed, 26 Mar 2003 16:51:30 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <001c01c2f3a0$bedf0900$[e-mail]>, "Joris Dobbelsteen" 
writes:
> The discussion regards whether TCP-MD5 is mandatory.
> There was a suggestion to open it up for other
> authentication mechansims.
> 
> Aren't there more methods for security beside
> TCP-MD5.


This discussion is regarding what to put in the BGP security section.

BGP is going to DS so a single implemented and deployed security
measure must be mandated.  TCP MD5 is widely implemented and widely
deployed.  Therefore the only choice is TCP MD5.

This particular discussion is not open to "would be nice" security
ideas.

Curtis



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA14268 for <[e-mail]>; Wed, 26 Mar 2003 09:05:35 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2A2B69127E; Wed, 26 Mar 2003 09:05:07 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D599E9127F; Wed, 26 Mar 2003 09:05:06 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A6E89127E for <[e-mail]>; Wed, 26 Mar 2003 09:05:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id F1A3F5E21D; Wed, 26 Mar 2003 09:05:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from cmailENV2.svr.pol.co.uk (cmailENV2.svr.pol.co.uk [213.218.77.54]) by segue.merit.edu (Postfix) with ESMTP id 258855E238 for <[e-mail]>; Wed, 26 Mar 2003 09:05:00 -0500 (EST)
Received: from [62.21.139.38] (helo=xtreme) by cmailENV2.svr.pol.co.uk with smtp (Exim 3.35 #1) id 18yBWS-0000OY-00 for [e-mail]; Wed, 26 Mar 2003 14:04:56 +0000
From: "Joris Dobbelsteen" <[e-mail]>
To: "IDR WG (E-mail)" <[e-mail]>
Subject: RE: Issue 19) Security Considerations 
Date: Wed, 26 Mar 2003 14:37:25 +0100
Message-ID: <001c01c2f3a0$bedf0900$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk

The discussion regards whether TCP-MD5 is mandatory.
There was a suggestion to open it up for other
authentication mechansims.

Aren't there more methods for security beside
TCP-MD5.

IPSec was considered, but due to larger overhead it
was assumed to be more vulnerable to certain DoS
attacks. For authentication it is better, as IPSec
is more likely to move the security needs. Next
IPSec becomes more and more deployed, including
intergraded hardware solutions for serveral network
devices.

I believe the security concern are regarding attacks
from a foreign network, not from the inside.
The attacks that are considered range from:

Data insertion:
IPSec provides high security against these kind of
attacks, including replay prevention.
TCP-MD5 protected data can be replayed with exactly
the same data. The channel is considered 'physically
secure', so the data cannot be obtained, only
inserted. Replay will be impossible.
A little notice is that TCP-MD5 doesn't secure
against establishing a channel, only whether the data
on it is valid.

Connection hyjacking:
IPSec provides security, against this, as the IPSec
channel would be infeasable to hyjack.
TCP-MD5 doesn't support rekeying, it is more
vulnerable than IPSec. The danger is attacks on the
key. The channel between two BGP routers is
considered 'secure', so it is impossible
to get traffic from it, only to insert it from
remote. Key detection will be impossible.

DoS (well I need a name):
IPSec has higher overhead for processing,
overloading a system much faster than with TCP-MD5.
However, IPSec can benefit from hardware that is
already deployed and widely supported.


The channels where BGP runs over are concidered
'secure'. It is thus assumed that an
adversery has no way to obtain traffic from the
BGP channels, except insert traffic.
The major thread is an adversery overloading the
BGP routers in such a way that they are become
unusable. Another treat is having an adversery
publishing incorrect results to the BGP router.

TCP-MD5 provides security, in a way that it does
authentication and protects the open channel. It
is a weak protocol not suitable for long-term or
high security implementations. It might be better
at with-standing DoS attacks, due to lower
processing overhead.

IPSec is really secure and is wider deployed than
TCP-MD5. IPSec provides much finer security
against attacks. I don't know of the performance
of IPSec is really much worse than TCP-MD5.

Using SSL or TLS is also an option, but it has
quite a high overhead and still suffers the same
issues (DoS attack).

Kerberos authentication is quite complex and also
has a lot of overhead. Also suffers from a DoS
attack.

Packet filters can prevent BGP routers from some
DoS attacks from the foreign network, but leaves
the vulnerability of attacks for the inside.

Other protocols are a good choice, with TCP
charactistics that aren't accesable from the
outside are a good choice, because these are
easily protected, especially against outside
attacks.


Next the option is to take another protocol besides
TCP. This would be a suggestion. For example, HTTP
can run over any protocol that is connection-oriented
and provides in-order delivery of the data. This
also counts for BGP, although the mainstream might
choose to select TCP.

A quick note to reliability. Considering the
transmission of packets, I does not care if we select
plain TCP, TCP with TCP-MD5 or TCP over IPSec, it 
all depends on the physical network and amount of
data transmitted (congestion).
TCP-MD5 and IPSec provide (resonable) security
against attacks. IPSec is more serious regarding
security from both external and internal treats.


*****
My recommendation is that a implementation might
support BGP over any protocol, but it MUST
be connection-oriented and the data* received in
order (*not the packets). It must also provide
recovery of lost information.
The implementation MUST support TCP,
which MUST be configurable by the admin
(on/off).

I would mention security and urge to implement
TCP-MD5 or IPSec as security mechanisms for BGP/TCP.
My opinion is to leave security to the implementors
of the protocol and not let it be part of the BGP
specification, because there are numberous of ways
to make BGP secure, with better methods than
TCP-MD5 and IPSec.
*****

Is relaxing the security requirements in the BGP
spec well-advised? No, well....
another view is that you don't require insufficient
or insecure methods that are actually outside the
scope of the specication. It is regarding a
routing protocol, it is NOT a security specification
of any kind. It is, however, required to mention
security is required to protect this protocol from
treats like connection hijacking, DoS attacks and
any more. You should advise about this, not
require it to be implemented.
The advise of the implemenation will usually promote
wide implementation of a method, so advise is
really useful for usability between different
implementation, but it is not advisible to require
something that is out of the scope of this
specification.


Well, I wasted my time writing this, at least you
wasted yours as well reading it ;-)

- Joris

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]On Behalf Of
>Curtis Villamizar
>Sent: Tuesday, 25 March 2003 21:32
>To: Alex Zinin
>Cc: John Leslie; [e-mail]
>Subject: Re: Issue 19) Security Considerations 
>
>
>
>In message <[e-mail]>, Alex Zinin writes:
>> John,
>> 
>>   Just so we are all on the same page, could please give your
>>   definition of "reliability" and explain how the MD5 option
>>   for TCP improves it?
>> 
>> Alex
>
>
>Just guessing, but maybe John means less pesky RSTs from the martians.
>
>Specifying TCP as the LCD is fine.  Requiring that implementations
>support TCP MD5 covers John's objection (IMHO).  He can turn it on if
>he wants to.  We don't mandate fast retransmit, fast recovery,
>new-reno, and a bunch of other TCP stuff (rfc2001) but we'd also like
>to see those in the BGP TCP implementation.
>
>Curtis
>
>
>> Tuesday, March 25, 2003, 5:13:08 AM, John Leslie wrote:
>> > Alex Zinin <[e-mail]> wrote:
>> >> 
>> >> John,
>> >> 
>> >> I'm sorry, I think I'm lost here a little... Did you 
>really mean to
>> >> say that plain TCP is not reliable enough as a transport protocol
>> >> while IPSEC and the MD5 option for TCP are, and suggest 
>to deprecate
>> >> BGP over plain TCP, or did I misread your message?
>> 
>> >    You certainly read it correctly. I do not believe plain TCP is
>> > reliable enough as a transport protocol for BGP. We're 
>talking critical
>> > network infrastructure here; and the minimum effect of 
>glitches that
>> > reach BGP is route-flapping.
>> 
>> >    I regard TCP-MD5 as a level 4 protocol with vastly improved
>> > reliability over plain TCP. Possibly others regard it as 
>something else
>> > -- which certainly could lead to confusion...
>> 
>> >    As the draft stands, it substitutes "TCP [RFC793]" for 
>"a reliable
>> > transport protocol". I regard that as a step backwards.
>> 
>> >    Further, I regard it as unwise to remove the language suggesting
>> > that the "reliable transport protocol" use authentication 
>in addition
>> > to anything specified here. (Sorry not to have mentioned 
>this sooner.)
>> 
>> > --
>> > John Leslie <[e-mail]>
>> 
>> >> Monday, March 24, 2003, 6:07:13 PM, John Leslie wrote:
>> >>> ...
>> >>> May I remind everyone where we started. In RFC1771:
>> >>> " 
>> >>> " BGP runs over a reliable transport protocol.  This 
>eliminates the
>> >>> " need to implement explicit update fragmentation, 
>retransmission,
>> >>> " acknowledgement, and sequencing.  Any authentication 
>scheme used by
>> >>> " the transport protocol may be used in addition to BGP's own
>> >>> " authentication mechanisms...
>> >> 
>> >>> Our current draft:
>> >>> " 
>> >> " BGP uses TCP [RFC793] as its transport protocol. This 
>eliminates the
>> >>> " need to implement explicit update fragmentation, 
>retransmission,
>> >>> " acknowledgment, and sequencing...
>> >> 
>> >>> From the very first time I read my first BGP RFC (many 
>years ago),
>> >>> I have thought that TCP simply wasn't "reliable" enough. 
>TCP-MD5 is
>> >>> reliable enough (IMHO). IPSEC is reliable enough (IMHO). No doubt
>> >>> there will be other contenders which will also be 
>reliable enough.
>> >>> But I really cringe at the thought of saying Plain-Old-TCP is
>> >>> reliable enough, provided the "implementation" allows for TCP-MD5
>> >>> (even though it may not work on the particular operating system).
>> >> 
>> >>> If we agree there's a problem with Plain-Old-TCP, we 
>should say so.
>> >>> Here, near the beginning: not stuffed away in 
>"implementation details"
>> >>> where everyone has fallen asleep long ago.
>> >> 
>> >>> Thus, if I may, I suggest:
>> >>> " 
>> >>> " BGP was designed to run over a reliable transport 
>protocol, which
>> >>> " eliminates the need to implement explicit update fragmentation,
>> >>> " retransmission, acknowledgement, and sequencing. Although some
>> >>> " current implementations use TCP [STD0007] without 
>authentication,
>> >>> " this is deprecated. BGP SHOULD use TCP-MD5 [RFC2385] as its
>> >>> " transport protocol, unless and until a better authenticated
>> >>> " transport protocol becomes available.
>> >> 
>> >>> --
>> >>> John Leslie <[e-mail]>
>> 
>> 
>


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA08486 for <[e-mail]>; Tue, 25 Mar 2003 15:32:50 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CD4F291271; Tue, 25 Mar 2003 15:32:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CAEE91272; Tue, 25 Mar 2003 15:32:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A37C91271 for <[e-mail]>; Tue, 25 Mar 2003 15:31:44 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 17BA45E155; Tue, 25 Mar 2003 15:31:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 426395E13F for <[e-mail]>; Tue, 25 Mar 2003 15:31:37 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA14559; Tue, 25 Mar 2003 15:31:49 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: John Leslie <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Tue, 25 Mar 2003 08:48:08 PST." <[e-mail]> 
Date: Tue, 25 Mar 2003 15:31:49 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Alex Zinin writes:
> John,
> 
>   Just so we are all on the same page, could please give your
>   definition of "reliability" and explain how the MD5 option
>   for TCP improves it?
> 
> Alex


Just guessing, but maybe John means less pesky RSTs from the martians.

Specifying TCP as the LCD is fine.  Requiring that implementations
support TCP MD5 covers John's objection (IMHO).  He can turn it on if
he wants to.  We don't mandate fast retransmit, fast recovery,
new-reno, and a bunch of other TCP stuff (rfc2001) but we'd also like
to see those in the BGP TCP implementation.

Curtis


> Tuesday, March 25, 2003, 5:13:08 AM, John Leslie wrote:
> > Alex Zinin <[e-mail]> wrote:
> >> 
> >> John,
> >> 
> >> I'm sorry, I think I'm lost here a little... Did you really mean to
> >> say that plain TCP is not reliable enough as a transport protocol
> >> while IPSEC and the MD5 option for TCP are, and suggest to deprecate
> >> BGP over plain TCP, or did I misread your message?
> 
> >    You certainly read it correctly. I do not believe plain TCP is
> > reliable enough as a transport protocol for BGP. We're talking critical
> > network infrastructure here; and the minimum effect of glitches that
> > reach BGP is route-flapping.
> 
> >    I regard TCP-MD5 as a level 4 protocol with vastly improved
> > reliability over plain TCP. Possibly others regard it as something else
> > -- which certainly could lead to confusion...
> 
> >    As the draft stands, it substitutes "TCP [RFC793]" for "a reliable
> > transport protocol". I regard that as a step backwards.
> 
> >    Further, I regard it as unwise to remove the language suggesting
> > that the "reliable transport protocol" use authentication in addition
> > to anything specified here. (Sorry not to have mentioned this sooner.)
> 
> > --
> > John Leslie <[e-mail]>
> 
> >> Monday, March 24, 2003, 6:07:13 PM, John Leslie wrote:
> >>> ...
> >>> May I remind everyone where we started. In RFC1771:
> >>> " 
> >>> " BGP runs over a reliable transport protocol.  This eliminates the
> >>> " need to implement explicit update fragmentation, retransmission,
> >>> " acknowledgement, and sequencing.  Any authentication scheme used by
> >>> " the transport protocol may be used in addition to BGP's own
> >>> " authentication mechanisms...
> >> 
> >>> Our current draft:
> >>> " 
> >> " BGP uses TCP [RFC793] as its transport protocol. This eliminates the
> >>> " need to implement explicit update fragmentation, retransmission,
> >>> " acknowledgment, and sequencing...
> >> 
> >>> From the very first time I read my first BGP RFC (many years ago),
> >>> I have thought that TCP simply wasn't "reliable" enough. TCP-MD5 is
> >>> reliable enough (IMHO). IPSEC is reliable enough (IMHO). No doubt
> >>> there will be other contenders which will also be reliable enough.
> >>> But I really cringe at the thought of saying Plain-Old-TCP is
> >>> reliable enough, provided the "implementation" allows for TCP-MD5
> >>> (even though it may not work on the particular operating system).
> >> 
> >>> If we agree there's a problem with Plain-Old-TCP, we should say so.
> >>> Here, near the beginning: not stuffed away in "implementation details"
> >>> where everyone has fallen asleep long ago.
> >> 
> >>> Thus, if I may, I suggest:
> >>> " 
> >>> " BGP was designed to run over a reliable transport protocol, which
> >>> " eliminates the need to implement explicit update fragmentation,
> >>> " retransmission, acknowledgement, and sequencing. Although some
> >>> " current implementations use TCP [STD0007] without authentication,
> >>> " this is deprecated. BGP SHOULD use TCP-MD5 [RFC2385] as its
> >>> " transport protocol, unless and until a better authenticated
> >>> " transport protocol becomes available.
> >> 
> >>> --
> >>> John Leslie <[e-mail]>
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA00816 for <[e-mail]>; Tue, 25 Mar 2003 11:48:40 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 91C8391262; Tue, 25 Mar 2003 11:48:26 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D70491264; Tue, 25 Mar 2003 11:48:26 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE37191262 for <[e-mail]>; Tue, 25 Mar 2003 11:48:24 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D3D165E0C8; Tue, 25 Mar 2003 11:48:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 9E6BA5DE7E for <[e-mail]>; Tue, 25 Mar 2003 11:48:24 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18xrb4-000HEe-00; Tue, 25 Mar 2003 08:48:23 -0800
Date: Tue, 25 Mar 2003 08:48:08 -0800
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: John Leslie <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations
In-Reply-To: <20030325081308.B10808@verdi>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <20030324210713.I12711@verdi> <[e-mail]> <20030325081308.B10808@verdi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

John,

  Just so we are all on the same page, could please give your
  definition of "reliability" and explain how the MD5 option
  for TCP improves it?

-- 
Alex

Tuesday, March 25, 2003, 5:13:08 AM, John Leslie wrote:
> Alex Zinin <[e-mail]> wrote:
>> 
>> John,
>> 
>> I'm sorry, I think I'm lost here a little... Did you really mean to
>> say that plain TCP is not reliable enough as a transport protocol
>> while IPSEC and the MD5 option for TCP are, and suggest to deprecate
>> BGP over plain TCP, or did I misread your message?

>    You certainly read it correctly. I do not believe plain TCP is
> reliable enough as a transport protocol for BGP. We're talking critical
> network infrastructure here; and the minimum effect of glitches that
> reach BGP is route-flapping.

>    I regard TCP-MD5 as a level 4 protocol with vastly improved
> reliability over plain TCP. Possibly others regard it as something else
> -- which certainly could lead to confusion...

>    As the draft stands, it substitutes "TCP [RFC793]" for "a reliable
> transport protocol". I regard that as a step backwards.

>    Further, I regard it as unwise to remove the language suggesting
> that the "reliable transport protocol" use authentication in addition
> to anything specified here. (Sorry not to have mentioned this sooner.)

> --
> John Leslie <[e-mail]>

>> Monday, March 24, 2003, 6:07:13 PM, John Leslie wrote:
>>> ...
>>> May I remind everyone where we started. In RFC1771:
>>> " 
>>> " BGP runs over a reliable transport protocol.  This eliminates the
>>> " need to implement explicit update fragmentation, retransmission,
>>> " acknowledgement, and sequencing.  Any authentication scheme used by
>>> " the transport protocol may be used in addition to BGP's own
>>> " authentication mechanisms...
>> 
>>> Our current draft:
>>> " 
>> " BGP uses TCP [RFC793] as its transport protocol. This eliminates the
>>> " need to implement explicit update fragmentation, retransmission,
>>> " acknowledgment, and sequencing...
>> 
>>> From the very first time I read my first BGP RFC (many years ago),
>>> I have thought that TCP simply wasn't "reliable" enough. TCP-MD5 is
>>> reliable enough (IMHO). IPSEC is reliable enough (IMHO). No doubt
>>> there will be other contenders which will also be reliable enough.
>>> But I really cringe at the thought of saying Plain-Old-TCP is
>>> reliable enough, provided the "implementation" allows for TCP-MD5
>>> (even though it may not work on the particular operating system).
>> 
>>> If we agree there's a problem with Plain-Old-TCP, we should say so.
>>> Here, near the beginning: not stuffed away in "implementation details"
>>> where everyone has fallen asleep long ago.
>> 
>>> Thus, if I may, I suggest:
>>> " 
>>> " BGP was designed to run over a reliable transport protocol, which
>>> " eliminates the need to implement explicit update fragmentation,
>>> " retransmission, acknowledgement, and sequencing. Although some
>>> " current implementations use TCP [STD0007] without authentication,
>>> " this is deprecated. BGP SHOULD use TCP-MD5 [RFC2385] as its
>>> " transport protocol, unless and until a better authenticated
>>> " transport protocol becomes available.
>> 
>>> --
>>> John Leslie <[e-mail]>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA12189 for <[e-mail]>; Tue, 25 Mar 2003 02:53:17 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2DE3191253; Tue, 25 Mar 2003 02:52:57 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E997891254; Tue, 25 Mar 2003 02:52:56 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8238B91253 for <[e-mail]>; Tue, 25 Mar 2003 02:52:55 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6001B5E05A; Tue, 25 Mar 2003 02:52:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 394F15DF33 for <[e-mail]>; Tue, 25 Mar 2003 02:52:55 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18xjEg-000OWe-00; Mon, 24 Mar 2003 23:52:42 -0800
Date: Mon, 24 Mar 2003 23:52:25 -0800
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: John Leslie <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>, [e-mail]
Subject: Re: Issue 19) Security Considerations
In-Reply-To: <20030324210713.I12711@verdi>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <20030324210713.I12711@verdi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

John,

  I'm sorry, I think I'm lost here a little... Did you really mean to
  say that plain TCP is not reliable enough as a transport protocol
  while IPSEC and the MD5 option for TCP are, and suggest to deprecate
  BGP over plain TCP, or did I misread your message?

-- 
Alex

Monday, March 24, 2003, 6:07:13 PM, John Leslie wrote:
> Alex Zinin <[e-mail]> wrote:
>> Jeffrey Haas <[e-mail]> wrote:
>>> Alex Zinin <[e-mail]> wrote:
>>> Jeffrey Haas <[e-mail]> wrote:
>> 
>>>>> To be pedantic, "BGP uses TCP-MD5 [RFC2385] as its transport protocol."
>>>> 
>>>> Is this your proposed text, or what you think the above reads as?
>>> 
>>> My observation is that if TCP-MD5 is a MUST, then we should refer
>>> to it that way throughout the document.
>> 
>> Hmmm... there is a difference between having to support MD5 so the
>> admin can turn this on, and always running over TCP-MD5. Your text
>> seems to mean the latter.

>    May I remind everyone where we started. In RFC1771:
> " 
> " BGP runs over a reliable transport protocol.  This eliminates the
> " need to implement explicit update fragmentation, retransmission,
> " acknowledgement, and sequencing.  Any authentication scheme used by
> " the transport protocol may be used in addition to BGP's own
> " authentication mechanisms...

>    Our current draft:
> " 
> " BGP uses TCP [RFC793] as its transport protocol. This eliminates the
> " need to implement explicit update fragmentation, retransmission,
> " acknowledgment, and sequencing...

>    From the very first time I read my first BGP RFC (many years ago),
> I have thought that TCP simply wasn't "reliable" enough. TCP-MD5 is
> reliable enough (IMHO). IPSEC is reliable enough (IMHO). No doubt
> there will be other contenders which will also be reliable enough.
> But I really cringe at the thought of saying Plain-Old-TCP is
> reliable enough, provided the "implementation" allows for TCP-MD5
> (even though it may not work on the particular operating system).

>    If we agree there's a problem with Plain-Old-TCP, we should say so.
> Here, near the beginning: not stuffed away in "implementation details"
> where everyone has fallen asleep long ago.

>    Thus, if I may, I suggest:
> " 
> " BGP was designed to run over a reliable transport protocol, which
> " eliminates the need to implement explicit update fragmentation,
> " retransmission, acknowledgement, and sequencing. Although some
> " current implementations use TCP [STD0007] without authentication,
> " this is deprecated. BGP SHOULD use TCP-MD5 [RFC2385] as its
> " transport protocol, unless and until a better authenticated
> " transport protocol becomes available.

> --
> John Leslie <[e-mail]>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA11770 for <[e-mail]>; Tue, 25 Mar 2003 02:40:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4131191252; Tue, 25 Mar 2003 02:40:29 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0EE7D91253; Tue, 25 Mar 2003 02:40:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0241F91252 for <[e-mail]>; Tue, 25 Mar 2003 02:40:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D5BBB5E056; Tue, 25 Mar 2003 02:40:26 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 79EE95E035 for <[e-mail]>; Tue, 25 Mar 2003 02:40:25 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18xj2S-000NHG-00; Mon, 24 Mar 2003 23:40:04 -0800
Date: Mon, 24 Mar 2003 23:39:31 -0800
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Kunihiro Ishiguro <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>, [e-mail], "Steven M.Bellovin" <[e-mail]>
Subject: Re: Issue 19) Security Considerations
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Ishi-

>>The security considerations section needs to provide the security
>>analysis of the protocol (which will be in a separate doc in our
>>case), as well as a mandatory to implement authentication mechanism.
>>Because BGP goes to DS, the authentication mechanisms (as well as all
>>other features) must have actually been implemented and deployed.

> IPv6 claim IPsec as MUST.  OSPFv3 use IPsec for routing
> authentication.  Same as PIM-SM (it says MAY not MUST though).  Now
> BGP is going to claim TCP MD5 as only solution and not consider IPsec
> at all.

I think the suggestion to say "MUST support TCP-MD5 and SHOULD support
IPSEC" was reasonable...

> Shouldn't we have global view for routing protocol security?
> I was expecting that RPSEC WG does it.

Bringing everyone on the same page was one of the reasons RPSEC
was created. We're still not there, though.

> Just for TCP protection problem, having two standard is not a good
> idea.

Generally you're correct. In the particular case of BGP, removing MD5
from the spec and mandating IPSEC, I think, would be problematic for
the reasons discussed in this thread before.

Regards

Alex



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA02094 for <[e-mail]>; Mon, 24 Mar 2003 22:09:14 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1AC669124A; Mon, 24 Mar 2003 22:08:46 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC8AC9124B; Mon, 24 Mar 2003 22:08:45 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A1DA79124A for <[e-mail]>; Mon, 24 Mar 2003 22:08:44 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8E9995E005; Mon, 24 Mar 2003 22:08:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id B99FD5E032 for <[e-mail]>; Mon, 24 Mar 2003 22:08:43 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA08797; Mon, 24 Mar 2003 22:09:12 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: Alex Zinin <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Mon, 24 Mar 2003 19:20:16 EST." <[e-mail]> 
Date: Mon, 24 Mar 2003 22:09:12 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Jeffrey Haas writes:
> On Mon, Mar 24, 2003 at 04:15:41PM -0800, Alex Zinin wrote:
> > Agreed. Though, I don't think you have to prove that your
> > implementation supports MD5 on every possible OS before you can claim
> > STD compliance. You just don't control those things.
> 
> We have found the various testing organizations.... entertaining to
> deal with on subjects like this.  Were this not the case, I would
> be silent on this issue.
> 
> > > To be pedantic, "BGP uses TCP-MD5 [RFC2385] as its transport protocol."
> > 
> > Is this your proposed text, or what you think the above reads as?
> 
> My observation is that if TCP-MD5 is a MUST, then we should refer
> to it that way throughout the document.
> 
> > Alex
> 
> -- 
> Jeff Haas 
> NextHop Technologies


There is no requirement that the security considerations have to
repeated throughout the document.

Curtis



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA28719 for <[e-mail]>; Mon, 24 Mar 2003 20:31:36 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B062A91249; Mon, 24 Mar 2003 20:31:17 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8828B9124A; Mon, 24 Mar 2003 20:31:17 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24AB091249 for <[e-mail]>; Mon, 24 Mar 2003 20:31:12 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C057C5E00A; Mon, 24 Mar 2003 20:31:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (mail.ipinfusion.com [65.223.109.2]) by segue.merit.edu (Postfix) with ESMTP id 49DAA5DF54 for <[e-mail]>; Mon, 24 Mar 2003 20:31:00 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2P1TWVI003744; Tue, 25 Mar 2003 10:29:32 +0900
Date: Mon, 24 Mar 2003 17:29:32 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>, [e-mail], "Steven M.Bellovin" <[e-mail]>
Subject: Re: Issue 19) Security Considerations
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>The security considerations section needs to provide the security
>analysis of the protocol (which will be in a separate doc in our
>case), as well as a mandatory to implement authentication mechanism.
>Because BGP goes to DS, the authentication mechanisms (as well as all
>other features) must have actually been implemented and deployed.

IPv6 claim IPsec as MUST.  OSPFv3 use IPsec for routing
authentication.  Same as PIM-SM (it says MAY not MUST though).  Now
BGP is going to claim TCP MD5 as only solution and not consider IPsec
at all.  Shouldn't we have global view for routing protocol security?

I was expecting that RPSEC WG does it.

Just for TCP protection problem, having two standard is not a good
idea.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA27768 for <[e-mail]>; Mon, 24 Mar 2003 20:04:21 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id ED14091246; Mon, 24 Mar 2003 20:03:59 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8B4391247; Mon, 24 Mar 2003 20:03:59 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AEB3791246 for <[e-mail]>; Mon, 24 Mar 2003 20:03:58 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8BBFC5E01B; Mon, 24 Mar 2003 20:03:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 0BDA15DFF2 for <[e-mail]>; Mon, 24 Mar 2003 20:03:58 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2P13uMo034922; Mon, 24 Mar 2003 20:03:56 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2P13qwu033967; Mon, 24 Mar 2003 20:03:52 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2P13lU23775; Mon, 24 Mar 2003 20:03:47 -0500 (EST)
Date: Mon, 24 Mar 2003 20:03:47 -0500
From: Jeffrey Haas <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Mar 24, 2003 at 04:43:57PM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Mar 24, 2003 at 04:43:57PM -0800, Alex Zinin wrote:
> Maybe we should change the text to say
> 
>  "Implementations MUST support TCP MD5 [RFC2385] for authentication."

And there would be much rejoicing (as Jeff shuts up).

> Alex

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA27197 for <[e-mail]>; Mon, 24 Mar 2003 19:47:30 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9B5D391245; Mon, 24 Mar 2003 19:47:19 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66FDE91246; Mon, 24 Mar 2003 19:47:19 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B8BEA91245 for <[e-mail]>; Mon, 24 Mar 2003 19:47:09 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 964935E01B; Mon, 24 Mar 2003 19:47:09 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 6784B5DFFB for <[e-mail]>; Mon, 24 Mar 2003 19:47:09 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18xcak-000Gpw-00; Mon, 24 Mar 2003 16:47:02 -0800
Date: Mon, 24 Mar 2003 16:45:04 -0800
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: David Meyer <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>, [e-mail]
Subject: Re: Issue 19) Security Considerations
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

David,

 Stop reading my mind! :)

-- 
Alex

Monday, March 24, 2003, 4:39:27 PM, David Meyer wrote:
>>> > My observation is that if TCP-MD5 is a MUST, then we should refer
>>> > to it that way throughout the document.
>>> 
>>> Hmmm... there is a difference between having to support MD5 so the
>>> admin can turn this on, and always running over TCP-MD5. Your text
>>> seems to mean the latter.

> Wouldn't the latter be an operational consideration, and if it were,
> shouldn't the text should specify the former? At the very least
> it (requiring TCP-MD5 on) does not reflect reality in the field. 

> Dave



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA27156 for <[e-mail]>; Mon, 24 Mar 2003 19:46:36 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DAA1A91248; Mon, 24 Mar 2003 19:46:17 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4047291247; Mon, 24 Mar 2003 19:46:16 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 049EA91246 for <[e-mail]>; Mon, 24 Mar 2003 19:46:11 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 990D95E01E; Mon, 24 Mar 2003 19:46:01 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 6935A5E01B for <[e-mail]>; Mon, 24 Mar 2003 19:46:01 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18xcZe-000GjJ-00; Mon, 24 Mar 2003 16:45:55 -0800
Date: Mon, 24 Mar 2003 16:43:57 -0800
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Jeff-

>> Hmmm... there is a difference between having to support MD5 so the
>> admin can turn this on, and always running over TCP-MD5. Your text
>> seems to mean the latter.

> This seems clear to me:
> :      Use of TCP MD5 [RFC2385] for authentication is mandatory.

> To me, this says "Thou shalt turn this on."

We shouldn't try to mandate operational practices in the spec, I
think, and saying something like "don't accept TCP connections without
MD5" would not fly, as this is not what implementations do in reality.

Maybe we should change the text to say

 "Implementations MUST support TCP MD5 [RFC2385] for authentication."

Alex



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA26933 for <[e-mail]>; Mon, 24 Mar 2003 19:39:14 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 11B5091244; Mon, 24 Mar 2003 19:39:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C54B391245; Mon, 24 Mar 2003 19:38:59 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5DE7F91244 for <[e-mail]>; Mon, 24 Mar 2003 19:38:58 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 4A4E95E01E; Mon, 24 Mar 2003 19:38:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by segue.merit.edu (Postfix) with ESMTP id BDEC05E01B for <[e-mail]>; Mon, 24 Mar 2003 19:38:57 -0500 (EST)
Received: (from dmm@localhost) by sith.maoz.com (8.12.8/8.12.8) id h2P0dRPD008085; Mon, 24 Mar 2003 16:39:27 -0800
Date: Mon, 24 Mar 2003 16:39:27 -0800
From: David Meyer <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>, [e-mail]
Subject: Re: Issue 19) Security Considerations
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Mar 24, 2003 at 04:32:58PM -0800
Sender: [e-mail]
Precedence: bulk

>> > My observation is that if TCP-MD5 is a MUST, then we should refer
>> > to it that way throughout the document.
>> 
>> Hmmm... there is a difference between having to support MD5 so the
>> admin can turn this on, and always running over TCP-MD5. Your text
>> seems to mean the latter.

Wouldn't the latter be an operational consideration, and if it were,
shouldn't the text should specify the former? At the very least
it (requiring TCP-MD5 on) does not reflect reality in the field. 

Dave


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA26856 for <[e-mail]>; Mon, 24 Mar 2003 19:38:23 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E129D91243; Mon, 24 Mar 2003 19:37:56 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ACC2691244; Mon, 24 Mar 2003 19:37:56 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8DE891243 for <[e-mail]>; Mon, 24 Mar 2003 19:37:55 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8DEE45DFF2; Mon, 24 Mar 2003 19:37:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 153FC5DFB3 for <[e-mail]>; Mon, 24 Mar 2003 19:37:55 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2P0brn1013802; Mon, 24 Mar 2003 19:37:53 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2P0blwu012953; Mon, 24 Mar 2003 19:37:47 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2P0bgM23715; Mon, 24 Mar 2003 19:37:42 -0500 (EST)
Date: Mon, 24 Mar 2003 19:37:42 -0500
From: Jeffrey Haas <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Mar 24, 2003 at 04:32:58PM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Mar 24, 2003 at 04:32:58PM -0800, Alex Zinin wrote:
> Hmmm... there is a difference between having to support MD5 so the
> admin can turn this on, and always running over TCP-MD5. Your text
> seems to mean the latter.

This seems clear to me:
:      Use of TCP MD5 [RFC2385] for authentication is mandatory.

To me, this says "Thou shalt turn this on."

> Alex

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA26764 for <[e-mail]>; Mon, 24 Mar 2003 19:35:26 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A4DC891241; Mon, 24 Mar 2003 19:35:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 707CF91243; Mon, 24 Mar 2003 19:35:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31B7391241 for <[e-mail]>; Mon, 24 Mar 2003 19:34:59 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0EFCF5E01E; Mon, 24 Mar 2003 19:34:59 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id D893C5DFF2 for <[e-mail]>; Mon, 24 Mar 2003 19:34:58 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18xcOy-000FaY-00; Mon, 24 Mar 2003 16:34:52 -0800
Date: Mon, 24 Mar 2003 16:32:58 -0800
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Jeff-

> We have found the various testing organizations.... entertaining to
> deal with on subjects like this.  Were this not the case, I would
> be silent on this issue.

I'm not sure how much we can do about this...

>> > To be pedantic, "BGP uses TCP-MD5 [RFC2385] as its transport protocol."
>> 
>> Is this your proposed text, or what you think the above reads as?

> My observation is that if TCP-MD5 is a MUST, then we should refer
> to it that way throughout the document.

Hmmm... there is a difference between having to support MD5 so the
admin can turn this on, and always running over TCP-MD5. Your text
seems to mean the latter.

Alex



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA26267 for <[e-mail]>; Mon, 24 Mar 2003 19:20:50 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2076A91240; Mon, 24 Mar 2003 19:20:30 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC33B91241; Mon, 24 Mar 2003 19:20:29 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D229F91240 for <[e-mail]>; Mon, 24 Mar 2003 19:20:28 -0500 (EST)
Received: by segue.merit.edu (Postfix) id ADEA45E019; Mon, 24 Mar 2003 19:20:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 24E025DF11 for <[e-mail]>; Mon, 24 Mar 2003 19:20:28 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2P0KQsF032673; Mon, 24 Mar 2003 19:20:26 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2P0KLwu032112; Mon, 24 Mar 2003 19:20:21 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2P0KGa23686; Mon, 24 Mar 2003 19:20:16 -0500 (EST)
Date: Mon, 24 Mar 2003 19:20:16 -0500
From: Jeffrey Haas <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Mar 24, 2003 at 04:15:41PM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Mar 24, 2003 at 04:15:41PM -0800, Alex Zinin wrote:
> Agreed. Though, I don't think you have to prove that your
> implementation supports MD5 on every possible OS before you can claim
> STD compliance. You just don't control those things.

We have found the various testing organizations.... entertaining to
deal with on subjects like this.  Were this not the case, I would
be silent on this issue.

> > To be pedantic, "BGP uses TCP-MD5 [RFC2385] as its transport protocol."
> 
> Is this your proposed text, or what you think the above reads as?

My observation is that if TCP-MD5 is a MUST, then we should refer
to it that way throughout the document.

> Alex

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA26173 for <[e-mail]>; Mon, 24 Mar 2003 19:17:52 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7D91E9123E; Mon, 24 Mar 2003 19:17:39 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5186C91240; Mon, 24 Mar 2003 19:17:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 169679123E for <[e-mail]>; Mon, 24 Mar 2003 19:17:38 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E8A8D5E018; Mon, 24 Mar 2003 19:17:37 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id C35265DF11 for <[e-mail]>; Mon, 24 Mar 2003 19:17:37 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18xc8B-000E8m-00; Mon, 24 Mar 2003 16:17:31 -0800
Date: Mon, 24 Mar 2003 16:15:41 -0800
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Jeff-

>> In fact, one would have the same situation with
>> IPSec too...

> Note however that IPSec is pretty pervasive at the workstation level
> whereas TCP-MD5 is not.

Agreed. Though, I don't think you have to prove that your
implementation supports MD5 on every possible OS before you can claim
STD compliance. You just don't control those things.

>> > In the bgp draft, we state:
>> > :    BGP uses TCP [RFC793] as its transport protocol. This eliminates the
>> > :    need to implement explicit update fragmentation, retransmission,
>> > :    acknowledgment, and sequencing. BGP listens on TCP port 179.  The
>> > :    error notification mechanism used in BGP assumes that TCP supports a
>> > :    "graceful" close, i.e., that all outstanding data will be delivered
>> > :    before the connection is closed.
>> 
>> > If we're going to mandate TCP-MD5, *here* is the place we must do it.
>> > Otherwise, the stricture that:
>> > :       Use of TCP MD5 [RFC2385] for authentication is mandatory.
>> 
>> > conflicts with the simple TCP statement above.
>> 
>> Sorry, could you explain what conflict you see?

> To be pedantic, "BGP uses TCP-MD5 [RFC2385] as its transport protocol."

Is this your proposed text, or what you think the above reads as?

Alex



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA23433 for <[e-mail]>; Mon, 24 Mar 2003 17:36:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2533A9123D; Mon, 24 Mar 2003 17:36:20 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED3BC9123E; Mon, 24 Mar 2003 17:36:19 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D31F39123D for <[e-mail]>; Mon, 24 Mar 2003 17:36:18 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B434B5DFFE; Mon, 24 Mar 2003 17:36:18 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 67BE55DF34 for <[e-mail]>; Mon, 24 Mar 2003 17:36:18 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2OMaH3h053842; Mon, 24 Mar 2003 17:36:17 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2OMa8wu053570; Mon, 24 Mar 2003 17:36:08 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2OMa3F23473; Mon, 24 Mar 2003 17:36:03 -0500 (EST)
Date: Mon, 24 Mar 2003 17:36:03 -0500
From: Jeffrey Haas <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Mar 24, 2003 at 12:05:18PM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Alex,

On Mon, Mar 24, 2003 at 12:05:18PM -0800, Alex Zinin wrote:
> If such commands and API
> are supported, I would say that this implementation is as compliant as
> it can possibly be... 

As, for example, GateD is.  We have the API for it, you just supply
the relevant hooks into your OS of choice.

> In fact, one would have the same situation with
> IPSec too...

Note however that IPSec is pretty pervasive at the workstation level
whereas TCP-MD5 is not.

> 
> > In the bgp draft, we state:
> > :    BGP uses TCP [RFC793] as its transport protocol. This eliminates the
> > :    need to implement explicit update fragmentation, retransmission,
> > :    acknowledgment, and sequencing. BGP listens on TCP port 179.  The
> > :    error notification mechanism used in BGP assumes that TCP supports a
> > :    "graceful" close, i.e., that all outstanding data will be delivered
> > :    before the connection is closed.
> 
> > If we're going to mandate TCP-MD5, *here* is the place we must do it.
> > Otherwise, the stricture that:
> > :       Use of TCP MD5 [RFC2385] for authentication is mandatory.
> 
> > conflicts with the simple TCP statement above.
> 
> Sorry, could you explain what conflict you see?

To be pedantic, "BGP uses TCP-MD5 [RFC2385] as its transport protocol."

> The security considerations section needs to provide the security
> analysis of the protocol (which will be in a separate doc in our
> case), as well as a mandatory to implement authentication mechanism.

This was the piece I needed to see.  Thanks.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA21674 for <[e-mail]>; Mon, 24 Mar 2003 15:07:00 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id C5ED091239; Mon, 24 Mar 2003 15:06:21 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93BC19123B; Mon, 24 Mar 2003 15:06:21 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52C7691239 for <[e-mail]>; Mon, 24 Mar 2003 15:06:20 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3A2C65DFE4; Mon, 24 Mar 2003 15:06:20 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id AF99D5DF85 for <[e-mail]>; Mon, 24 Mar 2003 15:06:18 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 18xYCv-000Icm-00; Mon, 24 Mar 2003 12:06:09 -0800
Date: Mon, 24 Mar 2003 12:05:18 -0800
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail], "Steven M.Bellovin" <[e-mail]>
Subject: Re: Issue 19) Security Considerations
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Jeff-

[...]
> A concern that Kunihiro has, being the implementor of a software-based
> BGP implmentation, is that by mandating TCP-MD5, we have made any
> software implementation of BGP that runs on an operating system without
> TCP-MD5 in the TCP/IP implementation a non-compliant BGP implementation.

> To restate this for our AD's, we are tying the compliance of a BGP
> implementation to a protocol that is not BGP-related.

It is getting somewhat implementation-specific, but still...

Because of the development model, platform-independent implementations
of BGP can't include the TCP-MD5 mechanism in their distribution at
all. Instead, maximum they can do is support appropriate configuration
commands and socket API that would interface with the kernel. This
seems to be as far as it can get in general. If such commands and API
are supported, I would say that this implementation is as compliant as
it can possibly be... In fact, one would have the same situation with
IPSec too...

> In the bgp draft, we state:
> :    BGP uses TCP [RFC793] as its transport protocol. This eliminates the
> :    need to implement explicit update fragmentation, retransmission,
> :    acknowledgment, and sequencing. BGP listens on TCP port 179.  The
> :    error notification mechanism used in BGP assumes that TCP supports a
> :    "graceful" close, i.e., that all outstanding data will be delivered
> :    before the connection is closed.

> If we're going to mandate TCP-MD5, *here* is the place we must do it.
> Otherwise, the stricture that:
> :       Use of TCP MD5 [RFC2385] for authentication is mandatory.

> conflicts with the simple TCP statement above.

Sorry, could you explain what conflict you see?

> An implementation that uses IPSEC is at least, if not more secure than
> TCP-MD5, but is non-compliant if it doesn't have support for TCP-MD5.

> I'll ask this question of our AD's:
> What is the exact requirements that we need out of our security considerations
> section for BGP?

[I'm cc;ing Steve Bellovin so he can correct me if I'm wrong somewhere.]

The security considerations section needs to provide the security
analysis of the protocol (which will be in a separate doc in our
case), as well as a mandatory to implement authentication mechanism.
Because BGP goes to DS, the authentication mechanisms (as well as all
other features) must have actually been implemented and deployed.

>From RFC1264:

> 5.0 Requirements for Draft Standard
...
>    4) There must be evidence that all features of the protocol have
>       been tested, running between at least two implementations.  This
>       must include that all of the security features have been
>       demonstrated to operate, and that the mechanisms defined in the
>       protocol actually provide the intended protection.

--
Alex



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA19294 for <[e-mail]>; Mon, 24 Mar 2003 11:24:45 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DEB0191234; Mon, 24 Mar 2003 11:24:27 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B09D391235; Mon, 24 Mar 2003 11:24:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 921B191234 for <[e-mail]>; Mon, 24 Mar 2003 11:24:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 78B715DFC7; Mon, 24 Mar 2003 11:24:26 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 0A24A5DFC5 for <[e-mail]>; Mon, 24 Mar 2003 11:24:26 -0500 (EST)
Received: by sentry.gw.tislabs.com; id LAA01906; Mon, 24 Mar 2003 11:25:19 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma001874; Mon, 24 Mar 03 11:24:36 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2OGNfK11170; Mon, 24 Mar 2003 11:23:41 -0500 (EST)
Date: Mon, 24 Mar 2003 11:23:41 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

>This may be a leap of faith because we would be assuming that the
>outcome of RPSEC is that IPSEC is the right solution for BGP.

I don't believe that the RPSEC charter speaks to establishing solutions.

Just so people don't get the wrong idea.

The charter does speak to "Possible Future Work" that would include
evaluating, documenting or recommending security mechanisms.  But that's
later.

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA17314 for <[e-mail]>; Mon, 24 Mar 2003 09:24:16 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id C789491230; Mon, 24 Mar 2003 09:23:49 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9358491231; Mon, 24 Mar 2003 09:23:49 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76E7691230 for <[e-mail]>; Mon, 24 Mar 2003 09:23:48 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 642625DFB1; Mon, 24 Mar 2003 09:23:48 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 10DE75DE15 for <[e-mail]>; Mon, 24 Mar 2003 09:23:48 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2OENgS00114; Mon, 24 Mar 2003 06:23:42 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kunihiro Ishiguro <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-Reply-To: Your message of "Sat, 22 Mar 2003 20:47:03 PST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 24 Mar 2003 06:23:42 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Kunihiro,

> >TCP connection hijack has always been general security problem because
> >if you could snoop, you could break into a connection and inject
> >traffic.  The obvious solution was to encrypt the payload.  This still
> >left the TCP RST problem, but for most services the DoS was not such a
> >severe issue.
> >
> >BGP is a somewhat different problem because an attacker couldn't snoop
> >on a provider's network interior, but could inject traffic in.  Router
> >addresses were always well known and one port number was 179 only one
> >port number had to be guessed.  It took too few packets to sucessfully
> >send an RST just sweeping the port range.  TCP MD5 prevented this.
> >
> >More recently the problem of sending more traffic than the MD5 check
> >can handle has emerged as a problem.  IPSEC doesn't help.  Since the
> >IPSEC decryptions are more difficult computations IPSEC actaully makes
> >the problem worse.
> 
> Hmm.  This is interesting.  If MD5 is better than IPsec for DoS attack
> threat and we can extend it as a generic solution not only for BGP but
> also other TCP based protocols such as LDP, I'm ok with it.

LDP supports TCP MD5 today.

> I was told that IPsec is a generic solution for TCP/IP authentication.
> If TCP MD5 is the way to go for TCP authentication and there is a wide
> consensus for it, I can live with it.
> 
> I'm really wondering why we put ennormous effort to IPsec
> specification and it's deployment.

That is a valid question, but perhaps the IDR WG may not be
the right place to answer it.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA16148 for <[e-mail]>; Mon, 24 Mar 2003 07:28:10 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DAA3C9122B; Mon, 24 Mar 2003 07:27:48 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4937A9122F; Mon, 24 Mar 2003 07:27:47 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 995419122B for <[e-mail]>; Mon, 24 Mar 2003 07:27:45 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 718675DE6A; Mon, 24 Mar 2003 07:27:45 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id EBC1B5DE56 for <[e-mail]>; Mon, 24 Mar 2003 07:27:44 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12100; Mon, 24 Mar 2003 07:25:25 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp-analysis-00.txt
Date: Mon, 24 Mar 2003 07:25:25 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

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

	Title		: BGP-4 Protocol Analysis
	Author(s)	: D. Meyer, K. Patel
	Filename	: draft-ietf-idr-bgp-analysis-00.txt
	Pages		: 15
	Date		: 2003-3-20
	
The purpose of this report is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for'the second report', as
described in Section 6.0 of RFC 1264 [RFC1264].  In order to fulfill
the requirement, this report augments RFC 1774 [RFC1774] and
summarizes the key features of BGP protocol, and analyzes the
protocol with respect to scaling and performance.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp-analysis-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-analysis-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-analysis-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-analysis-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA14861 for <[e-mail]>; Sun, 23 Mar 2003 14:12:23 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 69E7891227; Sun, 23 Mar 2003 14:11:58 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BCCD91228; Sun, 23 Mar 2003 14:11:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5625691227 for <[e-mail]>; Sun, 23 Mar 2003 14:11:57 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3E9A45DF06; Sun, 23 Mar 2003 14:11:57 -0500 (EST)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 137475DF04 for <[e-mail]>; Sun, 23 Mar 2003 14:11:57 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18xAss-000Mzf-00; Sun, 23 Mar 2003 11:11:54 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sun, 23 Mar 2003 11:11:54 -0800
To: Curtis Villamizar <[e-mail]>
Cc: IDR WG <[e-mail]>
Subject: Re: Issue 19) Security Considerations 
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>>> We must have a security section that meets approval of the IESG.  If
>>> the IESG doesn't insist that we have a MUST in the security section,
>>> then changing to SHOULD would be OK.
>> in this day and age of net attacks, and considering the vulnerability,
>> would such relaxation be well-advised?
> No.

then i suggest we not waste more time discussing it



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA14762 for <[e-mail]>; Sun, 23 Mar 2003 14:09:29 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 236BA91226; Sun, 23 Mar 2003 14:09:08 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E775591227; Sun, 23 Mar 2003 14:09:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A672691226 for <[e-mail]>; Sun, 23 Mar 2003 14:09:06 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 7FB225DF04; Sun, 23 Mar 2003 14:09:06 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id B920D5DED1 for <[e-mail]>; Sun, 23 Mar 2003 14:09:05 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA93640; Sun, 23 Mar 2003 14:10:02 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Randy Bush <[e-mail]>
Cc: Curtis Villamizar <[e-mail]>, IDR WG <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Sun, 23 Mar 2003 11:03:19 PST." <[e-mail]> 
Date: Sun, 23 Mar 2003 14:10:01 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Randy Bush writes:
> > We must have a security section that meets approval of the IESG.  If
> > the IESG doesn't insist that we have a MUST in the security section,
> > then changing to SHOULD would be OK.
> 
> in this day and age of net attacks, and considering the vulnerability,
> would such relaxation be well-advised?
> 
> randy

No.  But the ISPs are not going to stop using TCP MD5 because we
recorded a SHOULD in the RFC rather than a MUST.

Curtis



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA14582 for <[e-mail]>; Sun, 23 Mar 2003 14:03:42 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9FD2B91225; Sun, 23 Mar 2003 14:03:22 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6791391226; Sun, 23 Mar 2003 14:03:22 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79D1391225 for <[e-mail]>; Sun, 23 Mar 2003 14:03:21 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 4FC345DF0C; Sun, 23 Mar 2003 14:03:21 -0500 (EST)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 1EC8F5DF04 for <[e-mail]>; Sun, 23 Mar 2003 14:03:21 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18xAka-000HK0-00; Sun, 23 Mar 2003 11:03:20 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sun, 23 Mar 2003 11:03:19 -0800
To: Curtis Villamizar <[e-mail]>
Cc: IDR WG <[e-mail]>
Subject: Re: Issue 19) Security Considerations 
References: <000101c2f169$9c65c2d0$[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> We must have a security section that meets approval of the IESG.  If
> the IESG doesn't insist that we have a MUST in the security section,
> then changing to SHOULD would be OK.

in this day and age of net attacks, and considering the vulnerability,
would such relaxation be well-advised?

randy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA14292 for <[e-mail]>; Sun, 23 Mar 2003 13:56:03 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 405C091224; Sun, 23 Mar 2003 13:55:36 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C29791225; Sun, 23 Mar 2003 13:55:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9CD1291224 for <[e-mail]>; Sun, 23 Mar 2003 13:55:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 7F3315DF08; Sun, 23 Mar 2003 13:55:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id ECE235DF00 for <[e-mail]>; Sun, 23 Mar 2003 13:55:32 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA93317; Sun, 23 Mar 2003 13:56:49 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Joris Dobbelsteen" <[e-mail]>
Cc: [e-mail], "IDR WG (E-mail)" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Sun, 23 Mar 2003 19:21:49 +0100." <000101c2f169$9c65c2d0$[e-mail]> 
Date: Sun, 23 Mar 2003 13:56:48 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <000101c2f169$9c65c2d0$[e-mail]>, "Joris Dobbelsteen" 
writes:
> As it seems TCP MD5 and IPSec protect BGP sufficiently,
> except for DoS attack where the server is overloaded.
> It looks like filtering could solve this problem. This
> filtering can be done on the network border and/or at
> the BGP host. IPSec is quite nasty to filter for, if
> traffic is encrypted, TCP MD5 doesn't have this problem.
> 
> But perhaps that moving BGP to a secondary protocol, not
> related to IP in any way and allow only local hosts to
> send packets in this protocol (block it on the network
> borders) provides superiour protection against such attacks.
> This can also be done by a specific protocol inplemented on
> IP in the same way at the one above (block this protocol at
> the network border). The great disadvantage is you have to
> do what TCP (and IP) already do for you.
> One could use IPX/SPX for example. It has the features TCP
> has (sequenced in-order transmission) and there is still 
> some support for (I believe).
> 
> I would really recommend that BGP transmissions should be
> independent of the protocol being used. This might be TCP,
> IPX/SPX, anything else as long as it supports why the
> choice for TCP was made.
> 
> I would urge to have people pay attention to the security,
> but not by requirements. There might be better methods, only
> if someone implemented them.
> In case I would state one SHOULD implemented TCP MD5 to 
> promote interoperability between other BGP implementations.
> 
> - Joris


You make a good point regarding IPSEC and the inclusion of port
numbers in the encryption.  The port numbers would have to be excluded
from the encryption to make IPSEC viable for BGP in an ISP environment
where DoS attampts need to be tossed out at line rate.

Inventing or specifying new transport protocols for BGP is clearly
outside the scope of the update to BGP4.  BGP runs over TCP.  That is
the only current practice and we have strong consensus that it should
remain so at least for this iteration of BGP.

We must have a security section that meets approval of the IESG.  If
the IESG doesn't insist that we have a MUST in the security section,
then changing to SHOULD would be OK.

Curtis


> >-----Original Message-----
> >From: [e-mail] On Behalf Of Curtis Villamizar
> >Sent: Sunday, 23 March 2003 6:10
> >Subject: Re: Issue 19) Security Considerations 
> >
> >In message <[e-mail]>, Kunihiro Ishiguro writes:
> >> >TCP connection hijack has always been general security 
> >problem because
> >> >if you could snoop, you could break into a connection and inject
> >> >traffic.  The obvious solution was to encrypt the payload.  
> >This still
> >> >left the TCP RST problem, but for most services the DoS was 
> >not such a
> >> >severe issue.
> >> >
> >> >BGP is a somewhat different problem because an attacker 
> >couldn't snoop
> >> >on a provider's network interior, but could inject traffic 
> >in.  Router
> >> >addresses were always well known and one port number was 
> >179 only one
> >> >port number had to be guessed.  It took too few packets to 
> >sucessfully
> >> >send an RST just sweeping the port range.  TCP MD5 prevented this.
> >> >
> >> >More recently the problem of sending more traffic than the MD5 check
> >> >can handle has emerged as a problem.  IPSEC doesn't help.  Since the
> >> >IPSEC decryptions are more difficult computations IPSEC 
> >actaully makes
> >> >the problem worse.
> >> 
> >> Hmm.  This is interesting.  If MD5 is better than IPsec for 
> >DoS attack
> >> threat and we can extend it as a generic solution not only 
> >for BGP but
> >> also other TCP based protocols such as LDP, I'm ok with it.
> >> 
> >> I was told that IPsec is a generic solution for TCP/IP 
> >authentication.
> >> If TCP MD5 is the way to go for TCP authentication and there 
> >is a wide
> >> consensus for it, I can live with it.
> >
> >Both are vulnerable.  Therefore there has been no incentive to change.
> >
> >> I'm really wondering why we put ennormous effort to IPsec
> >> specification and it's deployment.
> >> -- 
> >> Kunihiro Ishiguro
> >
> >The situation where the better part of a gB of traffic is sent to a
> >router with addresses and ports spoofed is not considered the major
> >threat to such things as protecting a corporate intellectual property
> >or assets.  For generic security IPSEC is a good solution.
> >
> >For the very specialized requirements IPSEC is also just fine for
> >solving 1/2 the problem.  For the other half of the problem, neither
> >TCP MD5 or IPSEC is a solution.
> >
> >If someone could snoop BGP traffic, then IPSEC would be a better
> >solution.  That is not the case for ISPs.
> >
> >We are not here to argue whether IPSEC is a better solution than TCP
> >MD5 but rather what a BGP implementation needs to be plug into a
> >network and to be useful right now.  From the ISP perspective, it
> >needs TCP MD5 *regardless of what the IDR WG decides*.  As a WG we
> >need to recognize that.
> >
> >Therefore I agree with the course the WG was taking.  TCP MD5 should
> >be stated as a requirement (MUST) and IPSEC which may be in some ways
> >technically superior (ability to change keys and better encryption) in
> >ways that are almost irrelevant to the problem should at most be
> >stated as desireable (SHOULD).
> >
> >Later *if* IPSEC becomes very widely deployed as the means to protect
> >BGP, then we can reverse that.
> >
> >If anything this may point to a need to include DoS potentials and
> >their remedies in the BGP4 security section.
> >
> >Curtis
> >
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA13282 for <[e-mail]>; Sun, 23 Mar 2003 13:25:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 100A89120C; Sun, 23 Mar 2003 13:25:27 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEF4A91224; Sun, 23 Mar 2003 13:25:26 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8A2059120C for <[e-mail]>; Sun, 23 Mar 2003 13:25:25 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6A25D5DF08; Sun, 23 Mar 2003 13:25:25 -0500 (EST)
Delivered-To: [e-mail]
Received: from cmailENV2.svr.pol.co.uk (cmailENV2.svr.pol.co.uk [213.218.77.54]) by segue.merit.edu (Postfix) with ESMTP id 37D7E5DF06 for <[e-mail]>; Sun, 23 Mar 2003 13:25:25 -0500 (EST)
Received: from [62.21.130.27] (helo=xtreme) by cmailENV2.svr.pol.co.uk with smtp (Exim 3.35 #1) id 18xA9e-00079j-00; Sun, 23 Mar 2003 18:25:10 +0000
From: "Joris Dobbelsteen" <[e-mail]>
To: <[e-mail]>, "IDR WG (E-mail)" <[e-mail]>
Subject: RE: Issue 19) Security Considerations 
Date: Sun, 23 Mar 2003 19:21:49 +0100
Message-ID: <000101c2f169$9c65c2d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk

As it seems TCP MD5 and IPSec protect BGP sufficiently,
except for DoS attack where the server is overloaded.
It looks like filtering could solve this problem. This
filtering can be done on the network border and/or at
the BGP host. IPSec is quite nasty to filter for, if
traffic is encrypted, TCP MD5 doesn't have this problem.

But perhaps that moving BGP to a secondary protocol, not
related to IP in any way and allow only local hosts to
send packets in this protocol (block it on the network
borders) provides superiour protection against such attacks.
This can also be done by a specific protocol inplemented on
IP in the same way at the one above (block this protocol at
the network border). The great disadvantage is you have to
do what TCP (and IP) already do for you.
One could use IPX/SPX for example. It has the features TCP
has (sequenced in-order transmission) and there is still 
some support for (I believe).

I would really recommend that BGP transmissions should be
independent of the protocol being used. This might be TCP,
IPX/SPX, anything else as long as it supports why the
choice for TCP was made.

I would urge to have people pay attention to the security,
but not by requirements. There might be better methods, only
if someone implemented them.
In case I would state one SHOULD implemented TCP MD5 to 
promote interoperability between other BGP implementations.

- Joris

>-----Original Message-----
>From: [e-mail] On Behalf Of Curtis Villamizar
>Sent: Sunday, 23 March 2003 6:10
>Subject: Re: Issue 19) Security Considerations 
>
>In message <[e-mail]>, Kunihiro Ishiguro writes:
>> >TCP connection hijack has always been general security 
>problem because
>> >if you could snoop, you could break into a connection and inject
>> >traffic.  The obvious solution was to encrypt the payload.  
>This still
>> >left the TCP RST problem, but for most services the DoS was 
>not such a
>> >severe issue.
>> >
>> >BGP is a somewhat different problem because an attacker 
>couldn't snoop
>> >on a provider's network interior, but could inject traffic 
>in.  Router
>> >addresses were always well known and one port number was 
>179 only one
>> >port number had to be guessed.  It took too few packets to 
>sucessfully
>> >send an RST just sweeping the port range.  TCP MD5 prevented this.
>> >
>> >More recently the problem of sending more traffic than the MD5 check
>> >can handle has emerged as a problem.  IPSEC doesn't help.  Since the
>> >IPSEC decryptions are more difficult computations IPSEC 
>actaully makes
>> >the problem worse.
>> 
>> Hmm.  This is interesting.  If MD5 is better than IPsec for 
>DoS attack
>> threat and we can extend it as a generic solution not only 
>for BGP but
>> also other TCP based protocols such as LDP, I'm ok with it.
>> 
>> I was told that IPsec is a generic solution for TCP/IP 
>authentication.
>> If TCP MD5 is the way to go for TCP authentication and there 
>is a wide
>> consensus for it, I can live with it.
>
>Both are vulnerable.  Therefore there has been no incentive to change.
>
>> I'm really wondering why we put ennormous effort to IPsec
>> specification and it's deployment.
>> -- 
>> Kunihiro Ishiguro
>
>The situation where the better part of a gB of traffic is sent to a
>router with addresses and ports spoofed is not considered the major
>threat to such things as protecting a corporate intellectual property
>or assets.  For generic security IPSEC is a good solution.
>
>For the very specialized requirements IPSEC is also just fine for
>solving 1/2 the problem.  For the other half of the problem, neither
>TCP MD5 or IPSEC is a solution.
>
>If someone could snoop BGP traffic, then IPSEC would be a better
>solution.  That is not the case for ISPs.
>
>We are not here to argue whether IPSEC is a better solution than TCP
>MD5 but rather what a BGP implementation needs to be plug into a
>network and to be useful right now.  From the ISP perspective, it
>needs TCP MD5 *regardless of what the IDR WG decides*.  As a WG we
>need to recognize that.
>
>Therefore I agree with the course the WG was taking.  TCP MD5 should
>be stated as a requirement (MUST) and IPSEC which may be in some ways
>technically superior (ability to change keys and better encryption) in
>ways that are almost irrelevant to the problem should at most be
>stated as desireable (SHOULD).
>
>Later *if* IPSEC becomes very widely deployed as the means to protect
>BGP, then we can reverse that.
>
>If anything this may point to a need to include DoS potentials and
>their remedies in the BGP4 security section.
>
>Curtis
>


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA15050 for <[e-mail]>; Sun, 23 Mar 2003 00:08:40 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BADBB91222; Sun, 23 Mar 2003 00:08:18 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AC0491224; Sun, 23 Mar 2003 00:08:18 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2BC6391222 for <[e-mail]>; Sun, 23 Mar 2003 00:08:17 -0500 (EST)
Received: by segue.merit.edu (Postfix) id ED7B65DE8B; Sun, 23 Mar 2003 00:08:16 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id C839B5DDA0 for <[e-mail]>; Sun, 23 Mar 2003 00:08:15 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id AAA90831; Sun, 23 Mar 2003 00:09:37 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kunihiro Ishiguro <[e-mail]>
Cc: [e-mail], Randy Bush <[e-mail]>, [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Sat, 22 Mar 2003 20:47:03 PST." <[e-mail]> 
Date: Sun, 23 Mar 2003 00:09:37 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Kunihiro Ishiguro writes:
> >TCP connection hijack has always been general security problem because
> >if you could snoop, you could break into a connection and inject
> >traffic.  The obvious solution was to encrypt the payload.  This still
> >left the TCP RST problem, but for most services the DoS was not such a
> >severe issue.
> >
> >BGP is a somewhat different problem because an attacker couldn't snoop
> >on a provider's network interior, but could inject traffic in.  Router
> >addresses were always well known and one port number was 179 only one
> >port number had to be guessed.  It took too few packets to sucessfully
> >send an RST just sweeping the port range.  TCP MD5 prevented this.
> >
> >More recently the problem of sending more traffic than the MD5 check
> >can handle has emerged as a problem.  IPSEC doesn't help.  Since the
> >IPSEC decryptions are more difficult computations IPSEC actaully makes
> >the problem worse.
> 
> Hmm.  This is interesting.  If MD5 is better than IPsec for DoS attack
> threat and we can extend it as a generic solution not only for BGP but
> also other TCP based protocols such as LDP, I'm ok with it.
> 
> I was told that IPsec is a generic solution for TCP/IP authentication.
> If TCP MD5 is the way to go for TCP authentication and there is a wide
> consensus for it, I can live with it.

Both are vulnerable.  Therefore there has been no incentive to change.

> I'm really wondering why we put ennormous effort to IPsec
> specification and it's deployment.
> -- 
> Kunihiro Ishiguro

The situation where the better part of a gB of traffic is sent to a
router with addresses and ports spoofed is not considered the major
threat to such things as protecting a corporate intellectual property
or assets.  For generic security IPSEC is a good solution.

For the very specialized requirements IPSEC is also just fine for
solving 1/2 the problem.  For the other half of the problem, neither
TCP MD5 or IPSEC is a solution.

If someone could snoop BGP traffic, then IPSEC would be a better
solution.  That is not the case for ISPs.

We are not here to argue whether IPSEC is a better solution than TCP
MD5 but rather what a BGP implementation needs to be plug into a
network and to be useful right now.  From the ISP perspective, it
needs TCP MD5 *regardless of what the IDR WG decides*.  As a WG we
need to recognize that.

Therefore I agree with the course the WG was taking.  TCP MD5 should
be stated as a requirement (MUST) and IPSEC which may be in some ways
technically superior (ability to change keys and better encryption) in
ways that are almost irrelevant to the problem should at most be
stated as desireable (SHOULD).

Later *if* IPSEC becomes very widely deployed as the means to protect
BGP, then we can reverse that.

If anything this may point to a need to include DoS potentials and
their remedies in the BGP4 security section.

Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA14444 for <[e-mail]>; Sat, 22 Mar 2003 23:52:55 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 3D67191221; Sat, 22 Mar 2003 23:52:34 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D4C591222; Sat, 22 Mar 2003 23:52:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB1FE91221 for <[e-mail]>; Sat, 22 Mar 2003 23:52:31 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A1FC55DE88; Sat, 22 Mar 2003 23:52:31 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (ip-64-139-11-202.dsl.sca.megapath.net [64.139.11.202]) by segue.merit.edu (Postfix) with ESMTP id E76CF5DE42 for <[e-mail]>; Sat, 22 Mar 2003 23:52:30 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2N4p588011331; Sun, 23 Mar 2003 13:51:05 +0900
Date: Sat, 22 Mar 2003 20:51:05 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>To restate this for our AD's, we are tying the compliance of a BGP
>implementation to a protocol that is not BGP-related.
>
>In the bgp draft, we state:
>:    BGP uses TCP [RFC793] as its transport protocol. This eliminates the
>:    need to implement explicit update fragmentation, retransmission,
>:    acknowledgment, and sequencing. BGP listens on TCP port 179.  The
>:    error notification mechanism used in BGP assumes that TCP supports a
>:    "graceful" close, i.e., that all outstanding data will be delivered
>:    before the connection is closed.
>
>If we're going to mandate TCP-MD5, *here* is the place we must do it.
>Otherwise, the stricture that:
>:       Use of TCP MD5 [RFC2385] for authentication is mandatory.
>
>conflicts with the simple TCP statement above.
>
>An implementation that uses IPSEC is at least, if not more secure than
>TCP-MD5, but is non-compliant if it doesn't have support for TCP-MD5.
>
>I'll ask this question of our AD's:
>What is the exact requirements that we need out of our security considerations
>section for BGP?

Thanks Jeffrey.  You completely pointed out the issue.  Here I should
stop discussing and let AD to decide what to do.  I'll follow the
decision.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA14306 for <[e-mail]>; Sat, 22 Mar 2003 23:48:52 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D9FAF9121F; Sat, 22 Mar 2003 23:48:35 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DAA891221; Sat, 22 Mar 2003 23:48:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 875069121F for <[e-mail]>; Sat, 22 Mar 2003 23:48:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 60BBC5DE88; Sat, 22 Mar 2003 23:48:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (ip-64-139-11-202.dsl.sca.megapath.net [64.139.11.202]) by segue.merit.edu (Postfix) with ESMTP id A64D05DE72 for <[e-mail]>; Sat, 22 Mar 2003 23:48:33 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2N4l388011328; Sun, 23 Mar 2003 13:47:04 +0900
Date: Sat, 22 Mar 2003 20:47:03 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: [e-mail]
Cc: Randy Bush <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>TCP connection hijack has always been general security problem because
>if you could snoop, you could break into a connection and inject
>traffic.  The obvious solution was to encrypt the payload.  This still
>left the TCP RST problem, but for most services the DoS was not such a
>severe issue.
>
>BGP is a somewhat different problem because an attacker couldn't snoop
>on a provider's network interior, but could inject traffic in.  Router
>addresses were always well known and one port number was 179 only one
>port number had to be guessed.  It took too few packets to sucessfully
>send an RST just sweeping the port range.  TCP MD5 prevented this.
>
>More recently the problem of sending more traffic than the MD5 check
>can handle has emerged as a problem.  IPSEC doesn't help.  Since the
>IPSEC decryptions are more difficult computations IPSEC actaully makes
>the problem worse.

Hmm.  This is interesting.  If MD5 is better than IPsec for DoS attack
threat and we can extend it as a generic solution not only for BGP but
also other TCP based protocols such as LDP, I'm ok with it.

I was told that IPsec is a generic solution for TCP/IP authentication.
If TCP MD5 is the way to go for TCP authentication and there is a wide
consensus for it, I can live with it.

I'm really wondering why we put ennormous effort to IPsec
specification and it's deployment.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA13245 for <[e-mail]>; Sat, 22 Mar 2003 23:17:56 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D5D279121C; Sat, 22 Mar 2003 23:17:37 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3A039121F; Sat, 22 Mar 2003 23:17:37 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 443CB9121C for <[e-mail]>; Sat, 22 Mar 2003 23:17:36 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1E9F45DE8F; Sat, 22 Mar 2003 23:17:36 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id E47D95DE89 for <[e-mail]>; Sat, 22 Mar 2003 23:17:34 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id XAA90235; Sat, 22 Mar 2003 23:13:19 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kunihiro Ishiguro <[e-mail]>
Cc: Randy Bush <[e-mail]>, [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Sat, 22 Mar 2003 12:55:52 PST." <[e-mail]> 
Date: Sat, 22 Mar 2003 23:13:19 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Kunihiro Ishiguro writes:
> >> You may believe it or not, there are many BGP speakers which does not
> >> support TCP MD5.
> >
> >i believe this should be fixed.  bgp security is a very very scary
> >issue.
> 
> Yes it is very important issue.  IMHO, TCP MD5 does not solve BGP
> security issue.  It does not have any key exchange framework nor
> choice of algorithm.  It is just a simple MD5 signature in TCP option.
> 
> Almost implementation just accept static password for it and operators
> don't change it frequently.  It is scary.  Actually TCP MD5 option is
> not support some OS due to it does not provide good security.
> 
> I agree with that TCP MD5 is better than nothing.  But making it as
> only MUST item in BGP sepecification is wrong message for routing
> protocol security.
> -- 
> Kunihiro Ishiguro


TCP connection hijack has always been general security problem because
if you could snoop, you could break into a connection and inject
traffic.  The obvious solution was to encrypt the payload.  This still
left the TCP RST problem, but for most services the DoS was not such a
severe issue.

BGP is a somewhat different problem because an attacker couldn't snoop
on a provider's network interior, but could inject traffic in.  Router
addresses were always well known and one port number was 179 only one
port number had to be guessed.  It took too few packets to sucessfully
send an RST just sweeping the port range.  TCP MD5 prevented this.

More recently the problem of sending more traffic than the MD5 check
can handle has emerged as a problem.  IPSEC doesn't help.  Since the
IPSEC decryptions are more difficult computations IPSEC actaully makes
the problem worse.

The operators preference seems to still be to keep TCP MD5 in place
and take steps to prevent the newer problems from occuring.  These
have been filtering techniques including BTSH.  Incidentally if the
filtering goes into place (already in place for IBGP) TCP MD5 could in
principle be disabled, but it never hurts to have a backup defense.

Any claim that BGP is secure because it has MD5 *or* IPSEC is false.
The DoS threat is equal for both and if anything is greater for IPSEC.
A high traffic attack directed against the decryption will take either
one down.

If you knew what the real world problems were as opposed to the
security community imagined ones you'd have a better idea what was
scary and what was not a serious threat.  IPSEC is a fine solution for
some things but in this case its a solution looking for a problem and
it hasn't found a good match.

Personally I don't *care* which one gets used, but I *recognize* that
TCP MD5 is what is being used and understand the real problems facing
ISPs well enough to know that IPSEC doesn't address them.  Since we
are reviewing BGP for FS, we need to document the protocol as it
stands know, not as a subset of the WG think it should be.

Curtis

ps - dropping TCP MD5 into a BSD or Linux stack would not be a hard
thing to do and plenty of people have done it.  It might make a nice
addition to the ports collection if there is objections to putting
support in the base OS.  But that is irrelevant to the IDR discussion.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA10742 for <[e-mail]>; Sat, 22 Mar 2003 22:08:46 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A8C599121B; Sat, 22 Mar 2003 22:08:24 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 749399121C; Sat, 22 Mar 2003 22:08:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 276999121B for <[e-mail]>; Sat, 22 Mar 2003 22:08:23 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 04EED5DE11; Sat, 22 Mar 2003 22:08:23 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 4DC3A5DE0D for <[e-mail]>; Sat, 22 Mar 2003 22:08:22 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id WAA89816; Sat, 22 Mar 2003 22:04:07 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: Kunihiro Ishiguro <[e-mail]>, [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Sat, 22 Mar 2003 13:51:19 PST." <[e-mail]> 
Date: Sat, 22 Mar 2003 22:04:07 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, [e-mail]
dus.net writes:
> > >>We can change this to MUST either implement TCP MD5 or support host to
> > >>host IPSEC and SHOULD implement both.
> > >>
> > >>This may be a leap of faith because we would be assuming that the
> > >>outcome of RPSEC is that IPSEC is the right solution for BGP.
> > >>
> > >>Comments from others on this?
> > >
> > >TCP MD5 does not provide enough security framework to meet today's
> > >security requirement.  It only provide MD5 signature.  It is scary.
> > >If the the box has IPsec, there should not be need of less secure TCP
> > >MD5 option support.
> > 
> > I forgot to say my proposal.  "BGP protocol MUST support TCP MD5 or
> > IPsec".  When the box has IPsec, there is no need of encourage to
> > support less secure TCP MD5.
> 
> I would disagree.  All boxes must support at least the minimum security
> standard for interoperability.  If you want to connect a box that only
> supports MD5 and one that only supports IPSEC, you could not bring up
> an authenticated session between them.  I would be fine with something
> along the lines of: 
> 
> An implementation MUST support TCP MD5, and SHOULD support IPSEC.
> 
> Andrew

This is better than what I suggested.  It encourages transition but
recognizes that no transition has begun.

Curtis



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA10336 for <[e-mail]>; Sat, 22 Mar 2003 21:57:29 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 3E1569121A; Sat, 22 Mar 2003 21:57:07 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 161119121B; Sat, 22 Mar 2003 21:57:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DB8169121A for <[e-mail]>; Sat, 22 Mar 2003 21:57:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id BC3D55DE88; Sat, 22 Mar 2003 21:57:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 3C4095DE87 for <[e-mail]>; Sat, 22 Mar 2003 21:57:05 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2N2tgS18520; Sat, 22 Mar 2003 18:55:42 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Randy Bush <[e-mail]>
Cc: Kunihiro Ishiguro <[e-mail]>, [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-Reply-To: Your message of "Sat, 22 Mar 2003 14:50:24 PST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sat, 22 Mar 2003 18:55:42 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Randy,

> > TCP MD5 does not provide enough security framework to meet today's
> > security requirement.  It only provide MD5 signature.  It is scary.
> > If the the box has IPsec, there should not be need of less secure TCP
> > MD5 option support.
> 
> security folk who have done actual analyses, e.g., steve bellovin,
> agress that, for protecting bgp, the only advantage ipsec has over
> md5 is rekeying.  and rekeying is not our big problem, it's any
> keying at all.

Just to add, making TCP MD5 mandatory (MUST) have been discussed
on the mailing list before, and there was a consensus to make it
mandatory.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA01882 for <[e-mail]>; Sat, 22 Mar 2003 17:50:53 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6BCD491218; Sat, 22 Mar 2003 17:50:27 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41C5D9121A; Sat, 22 Mar 2003 17:50:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5405191218 for <[e-mail]>; Sat, 22 Mar 2003 17:50:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 32F1F5DE2C; Sat, 22 Mar 2003 17:50:26 -0500 (EST)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 102FA5DD97 for <[e-mail]>; Sat, 22 Mar 2003 17:50:26 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18wron-000Mhi-00; Sat, 22 Mar 2003 14:50:25 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sat, 22 Mar 2003 14:50:24 -0800
To: Kunihiro Ishiguro <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations 
References: <[e-mail]> <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> TCP MD5 does not provide enough security framework to meet today's
> security requirement.  It only provide MD5 signature.  It is scary.
> If the the box has IPsec, there should not be need of less secure TCP
> MD5 option support.

security folk who have done actual analyses, e.g., steve bellovin,
agress that, for protecting bgp, the only advantage ipsec has over
md5 is rekeying.  and rekeying is not our big problem, it's any
keying at all.

randy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA29781 for <[e-mail]>; Sat, 22 Mar 2003 16:54:54 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 196A391217; Sat, 22 Mar 2003 16:54:34 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF72F91218; Sat, 22 Mar 2003 16:54:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E991691217 for <[e-mail]>; Sat, 22 Mar 2003 16:54:32 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C9BB35DE69; Sat, 22 Mar 2003 16:54:32 -0500 (EST)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 7225F5DD97 for <[e-mail]>; Sat, 22 Mar 2003 16:54:32 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id NAA23716; Sat, 22 Mar 2003 13:51:19 -0800 (PST)
Date: Sat, 22 Mar 2003 13:51:19 -0800
From: [e-mail]
To: Kunihiro Ishiguro <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Sat, Mar 22, 2003 at 01:21:19PM -0800
Sender: [e-mail]
Precedence: bulk

> >>We can change this to MUST either implement TCP MD5 or support host to
> >>host IPSEC and SHOULD implement both.
> >>
> >>This may be a leap of faith because we would be assuming that the
> >>outcome of RPSEC is that IPSEC is the right solution for BGP.
> >>
> >>Comments from others on this?
> >
> >TCP MD5 does not provide enough security framework to meet today's
> >security requirement.  It only provide MD5 signature.  It is scary.
> >If the the box has IPsec, there should not be need of less secure TCP
> >MD5 option support.
> 
> I forgot to say my proposal.  "BGP protocol MUST support TCP MD5 or
> IPsec".  When the box has IPsec, there is no need of encourage to
> support less secure TCP MD5.

I would disagree.  All boxes must support at least the minimum security
standard for interoperability.  If you want to connect a box that only
supports MD5 and one that only supports IPSEC, you could not bring up
an authenticated session between them.  I would be fine with something
along the lines of: 

An implementation MUST support TCP MD5, and SHOULD support IPSEC.

Andrew


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA29655 for <[e-mail]>; Sat, 22 Mar 2003 16:51:01 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6A42F91216; Sat, 22 Mar 2003 16:50:25 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3602491217; Sat, 22 Mar 2003 16:50:25 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 199DB91216 for <[e-mail]>; Sat, 22 Mar 2003 16:50:24 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 01A895DE49; Sat, 22 Mar 2003 16:50:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 757355DD97 for <[e-mail]>; Sat, 22 Mar 2003 16:50:23 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2MLoMrN054484; Sat, 22 Mar 2003 16:50:22 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2MLoINp054477 for <[e-mail]>; Sat, 22 Mar 2003 16:50:18 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2MLoDY18760 for [e-mail]; Sat, 22 Mar 2003 16:50:13 -0500 (EST)
Date: Sat, 22 Mar 2003 16:50:13 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: Issue 19) Security Considerations
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Sat, Mar 22, 2003 at 08:40:56AM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

I would like to attempt to refocus Kunihiro's concern.

On Sat, Mar 22, 2003 at 08:40:56AM -0800, Kunihiro Ishiguro wrote:
> Anyway, my concern is putting TCP MD5 as only one MUST item in BGP
> security consideration section.  I want to hear technical opinin at
> here.

Our security conern is that there are several vulnerabilities on attacking
BGP-4 via the transport mechanism - in this case TCP.  The lowest
common denominator in hardware-based implementations of BGP (routers)
is TCP-MD5.  It serves the purpose of providing a much more secure 
transport session.

Any mechanism at least as strong as TCP-MD5 should be sufficient.

A concern that Kunihiro has, being the implementor of a software-based
BGP implmentation, is that by mandating TCP-MD5, we have made any
software implementation of BGP that runs on an operating system without
TCP-MD5 in the TCP/IP implementation a non-compliant BGP implementation.

To restate this for our AD's, we are tying the compliance of a BGP
implementation to a protocol that is not BGP-related.

In the bgp draft, we state:
:    BGP uses TCP [RFC793] as its transport protocol. This eliminates the
:    need to implement explicit update fragmentation, retransmission,
:    acknowledgment, and sequencing. BGP listens on TCP port 179.  The
:    error notification mechanism used in BGP assumes that TCP supports a
:    "graceful" close, i.e., that all outstanding data will be delivered
:    before the connection is closed.

If we're going to mandate TCP-MD5, *here* is the place we must do it.
Otherwise, the stricture that:
:       Use of TCP MD5 [RFC2385] for authentication is mandatory.

conflicts with the simple TCP statement above.

An implementation that uses IPSEC is at least, if not more secure than
TCP-MD5, but is non-compliant if it doesn't have support for TCP-MD5.

I'll ask this question of our AD's:
What is the exact requirements that we need out of our security considerations
section for BGP?

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA28689 for <[e-mail]>; Sat, 22 Mar 2003 16:23:15 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 461D691214; Sat, 22 Mar 2003 16:22:49 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15F3191216; Sat, 22 Mar 2003 16:22:49 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E824A91214 for <[e-mail]>; Sat, 22 Mar 2003 16:22:46 -0500 (EST)
Received: by segue.merit.edu (Postfix) id BD9D35DE63; Sat, 22 Mar 2003 16:22:46 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (ip-64-139-11-202.dsl.sca.megapath.net [64.139.11.202]) by segue.merit.edu (Postfix) with ESMTP id 1578D5DE62 for <[e-mail]>; Sat, 22 Mar 2003 16:22:46 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2MLLJ88001147; Sun, 23 Mar 2003 06:21:19 +0900
Date: Sat, 22 Mar 2003 13:21:19 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>>We can change this to MUST either implement TCP MD5 or support host to
>>host IPSEC and SHOULD implement both.
>>
>>This may be a leap of faith because we would be assuming that the
>>outcome of RPSEC is that IPSEC is the right solution for BGP.
>>
>>Comments from others on this?
>
>TCP MD5 does not provide enough security framework to meet today's
>security requirement.  It only provide MD5 signature.  It is scary.
>If the the box has IPsec, there should not be need of less secure TCP
>MD5 option support.

I forgot to say my proposal.  "BGP protocol MUST support TCP MD5 or
IPsec".  When the box has IPsec, there is no need of encourage to
support less secure TCP MD5.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA28398 for <[e-mail]>; Sat, 22 Mar 2003 16:14:14 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9972C91209; Sat, 22 Mar 2003 16:13:53 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6539091214; Sat, 22 Mar 2003 16:13:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2A5EC91209 for <[e-mail]>; Sat, 22 Mar 2003 16:13:52 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1A7065DE62; Sat, 22 Mar 2003 16:13:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from hotmail.com (bay1-f110.bay1.hotmail.com [65.54.245.110]) by segue.merit.edu (Postfix) with ESMTP id CD0135DE5F for <[e-mail]>; Sat, 22 Mar 2003 16:13:51 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 22 Mar 2003 13:13:51 -0800
Received: from 65.194.140.2 by by1fd.bay1.hotmail.msn.com with HTTP; Sat, 22 Mar 2003 21:13:50 GMT
X-Originating-IP: [65.194.140.2]
X-Originating-Email: [[e-mail]]
From: "Bruno Rijsman" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: questions about the index of the bgpM2PeerTable
Date: Sat, 22 Mar 2003 16:13:50 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 22 Mar 2003 21:13:51.0256 (UTC) FILETIME=[EFCB6180:01C2F0B7]
Sender: [e-mail]
Precedence: bulk

JH> My own thought is that in the case where the source address is not
JH> known ahead of time that a value of 0.0.0.0 (or all zeros for a
JH> given addrtype) would mean that its an unspecified address on
JH> configuration.
JH> It may be ok to leave this in the established state as well to
JH> make the tables queryable.  The implementations I have worked with
JH> tend to require you to specify the local end of the connection
JH> via configuration in some cases and when this is done, the value can
JH> be placed here.

Yes, I like your proposal: bgpM2PeerLocalAddr is the configured
(administrative) local address and 0.0.0.0 means no local address has
been configured.

We might want to add an additional object which is not part of the index
to retrieve the actual (operational) local address when the peer is
established. ( At least I think we need a separate object for that, but
I'm not really an SNMP expert, so feel free to correct me if I am wrong. )

And if we are really adventurous we might generalize this and say that
a bgpM2PeerRemoteAddr of 0.0.0.0 means that no remote address has been
configured (e.g. a promiscuous passive peer) and add an object for the
operational remote address.

-- Bruno

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA27813 for <[e-mail]>; Sat, 22 Mar 2003 15:57:43 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BA0AB91212; Sat, 22 Mar 2003 15:57:17 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85D8E91214; Sat, 22 Mar 2003 15:57:17 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5108591212 for <[e-mail]>; Sat, 22 Mar 2003 15:57:16 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3C6745DE5D; Sat, 22 Mar 2003 15:57:16 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (ip-64-139-11-202.dsl.sca.megapath.net [64.139.11.202]) by segue.merit.edu (Postfix) with ESMTP id 6FDC25DE54 for <[e-mail]>; Sat, 22 Mar 2003 15:57:15 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2MKtq88001101; Sun, 23 Mar 2003 05:55:52 +0900
Date: Sat, 22 Mar 2003 12:55:52 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: Randy Bush <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>> You may believe it or not, there are many BGP speakers which does not
>> support TCP MD5.
>
>i believe this should be fixed.  bgp security is a very very scary
>issue.

Yes it is very important issue.  IMHO, TCP MD5 does not solve BGP
security issue.  It does not have any key exchange framework nor
choice of algorithm.  It is just a simple MD5 signature in TCP option.

Almost implementation just accept static password for it and operators
don't change it frequently.  It is scary.  Actually TCP MD5 option is
not support some OS due to it does not provide good security.

I agree with that TCP MD5 is better than nothing.  But making it as
only MUST item in BGP sepecification is wrong message for routing
protocol security.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA27342 for <[e-mail]>; Sat, 22 Mar 2003 15:44:22 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A946791211; Sat, 22 Mar 2003 15:43:56 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7514891212; Sat, 22 Mar 2003 15:43:56 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D85B91211 for <[e-mail]>; Sat, 22 Mar 2003 15:43:55 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E67645DE5D; Sat, 22 Mar 2003 15:43:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (ip-64-139-11-202.dsl.sca.megapath.net [64.139.11.202]) by segue.merit.edu (Postfix) with ESMTP id 3C9525DE5A for <[e-mail]>; Sat, 22 Mar 2003 15:43:54 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2MKgQ88001077; Sun, 23 Mar 2003 05:42:27 +0900
Date: Sat, 22 Mar 2003 12:42:26 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>I suggest that a compromise is in order.
>
>We can change this to MUST either implement TCP MD5 or support host to
>host IPSEC and SHOULD implement both.
>
>This may be a leap of faith because we would be assuming that the
>outcome of RPSEC is that IPSEC is the right solution for BGP.
>
>Comments from others on this?

TCP MD5 does not provide enough security framework to meet today's
security requirement.  It only provide MD5 signature.  It is scary.
If the the box has IPsec, there should not be need of less secure TCP
MD5 option support.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA22551 for <[e-mail]>; Sat, 22 Mar 2003 13:28:31 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id EEEE59120A; Sat, 22 Mar 2003 13:28:06 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEC429120D; Sat, 22 Mar 2003 13:28:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C2D379120A for <[e-mail]>; Sat, 22 Mar 2003 13:28:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A162F5DE42; Sat, 22 Mar 2003 13:28:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id 7B0BC5DE41 for <[e-mail]>; Sat, 22 Mar 2003 13:28:04 -0500 (EST)
Received: by nomad.tcb.net (Postfix, from userid 500) id 029CF55F62; Sat, 22 Mar 2003 11:27:21 -0700 (MST)
Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id F398F3E83 for <[e-mail]>; Sat, 22 Mar 2003 11:27:21 -0700 (MST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: [e-mail]
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 22 Mar 2003 11:27:16 -0700
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> We can change this to MUST either implement TCP MD5 or support host to
> host IPSEC and SHOULD implement both.

I can deal with this.

> This may be a leap of faith because we would be assuming that the
> outcome of RPSEC is that IPSEC is the right solution for BGP.

It'll _never happen...

-danny



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA22239 for <[e-mail]>; Sat, 22 Mar 2003 13:20:11 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5C9D791208; Sat, 22 Mar 2003 13:19:45 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C7289120A; Sat, 22 Mar 2003 13:19:45 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 44D0A91208 for <[e-mail]>; Sat, 22 Mar 2003 13:19:44 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1DFD85DE3B; Sat, 22 Mar 2003 13:19:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id EB5525DDC8 for <[e-mail]>; Sat, 22 Mar 2003 13:19:43 -0500 (EST)
Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.12) id 18wnao-000OwF-00; Sat, 22 Mar 2003 10:19:42 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sat, 22 Mar 2003 10:19:42 -0800
To: Kunihiro Ishiguro <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations 
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> You may believe it or not, there are many BGP speakers which does not
> support TCP MD5.

i believe this should be fixed.  bgp security is a very very scary
issue.

randy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA20919 for <[e-mail]>; Sat, 22 Mar 2003 12:40:52 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id EA5BD91207; Sat, 22 Mar 2003 12:40:30 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B215E91208; Sat, 22 Mar 2003 12:40:29 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F19991207 for <[e-mail]>; Sat, 22 Mar 2003 12:40:28 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 586A55DE31; Sat, 22 Mar 2003 12:40:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 722945DE30 for <[e-mail]>; Sat, 22 Mar 2003 12:40:27 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA88528; Sat, 22 Mar 2003 12:37:37 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kunihiro Ishiguro <[e-mail]>
Cc: [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Sat, 22 Mar 2003 08:54:23 PST." <[e-mail]> 
Date: Sat, 22 Mar 2003 12:37:37 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Kunihiro Ishiguro writes:
> >This issue with the MUST is that we MUST address security in order 
> >to progress the base BGP document and as Andrew says, TCP MD5 is the 
> >lowest common denominator.
> 
> You may believe it or not, there are many BGP speakers which does not
> support TCP MD5.

All toys.  None of them suitable for ISP use.  Some are explicitly
designed for measurement purposes only (MRT).

> Please think about some guy implement BGP after that.  Is that a right
> way to enforce the guy to implement TCP MD5?  TCP MD5 is not BGP
> protocol at all.  You said common denominator, but from TCP/IP stack
> deployment TCP MD5 very minor extension.
> -- 
> Kunihiro Ishiguro

I suggest that a compromise is in order.

We can change this to MUST either implement TCP MD5 or support host to
host IPSEC and SHOULD implement both.

This may be a leap of faith because we would be assuming that the
outcome of RPSEC is that IPSEC is the right solution for BGP.

Comments from others on this?

Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA19396 for <[e-mail]>; Sat, 22 Mar 2003 11:56:24 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B38F191203; Sat, 22 Mar 2003 11:55:48 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8155A91205; Sat, 22 Mar 2003 11:55:48 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F1B291203 for <[e-mail]>; Sat, 22 Mar 2003 11:55:47 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 541365DE22; Sat, 22 Mar 2003 11:55:47 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (ip-64-139-11-202.dsl.sca.megapath.net [64.139.11.202]) by segue.merit.edu (Postfix) with ESMTP id A288D5DDFA for <[e-mail]>; Sat, 22 Mar 2003 11:55:46 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2MGsNti001125; Sun, 23 Mar 2003 01:54:23 +0900
Date: Sat, 22 Mar 2003 08:54:23 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-Reply-To: <[e-mail]>
References: <[e-mail]>
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>This issue with the MUST is that we MUST address security in order 
>to progress the base BGP document and as Andrew says, TCP MD5 is the 
>lowest common denominator.

You may believe it or not, there are many BGP speakers which does not
support TCP MD5.

Please think about some guy implement BGP after that.  Is that a right
way to enforce the guy to implement TCP MD5?  TCP MD5 is not BGP
protocol at all.  You said common denominator, but from TCP/IP stack
deployment TCP MD5 very minor extension.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA18927 for <[e-mail]>; Sat, 22 Mar 2003 11:42:53 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6BA5691201; Sat, 22 Mar 2003 11:42:31 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3564291203; Sat, 22 Mar 2003 11:42:31 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E074A91201 for <[e-mail]>; Sat, 22 Mar 2003 11:42:29 -0500 (EST)
Received: by segue.merit.edu (Postfix) id CA0835DE29; Sat, 22 Mar 2003 11:42:29 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (ip-64-139-11-202.dsl.sca.megapath.net [64.139.11.202]) by segue.merit.edu (Postfix) with ESMTP id 0E6D25DDFA for <[e-mail]>; Sat, 22 Mar 2003 11:42:29 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2MGeuti001119; Sun, 23 Mar 2003 01:40:57 +0900
Date: Sat, 22 Mar 2003 08:40:56 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: [e-mail]
Cc: [e-mail], "Naidu,    Venkata" <[e-mail]>, [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>We are not defining a new spec and moving it to PS.  We are reviewing
>and correcting an old spec and moving it to FS.  In doing so we must
>consider current implementations and current implementation
>experience.  Pretty good new ideas that are sparsely implemented and
>have near zero deployment have to be documented in other documents and
>can *later* be moved into the base spec after they are widely
>implemented and widely deployed.

Curtis,

You should look at real world, it is not made by only tier-1 network.
It is year 2003 not year 1993.  How can you say that there are 'near
zero deployment' ?  If we only consider Cisco and Juniper
implementation, actually there is no need of discussing at here.  Just
vendor's check is needed, isn't it?

I'm so sad that hearing such kind of depressing opinon from excellent
engineer like you.

Anyway, my concern is putting TCP MD5 as only one MUST item in BGP
security consideration section.  I want to hear technical opinin at
here.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA14581 for <[e-mail]>; Sat, 22 Mar 2003 09:57:37 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 628B49120F; Sat, 22 Mar 2003 09:57:01 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39C9B91209; Sat, 22 Mar 2003 09:57:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24B1D91209 for <[e-mail]>; Sat, 22 Mar 2003 09:56:59 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0DB445DE1A; Sat, 22 Mar 2003 09:56:59 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 56D905DD96 for <[e-mail]>; Sat, 22 Mar 2003 09:56:58 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id JAA87932; Sat, 22 Mar 2003 09:54:06 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kunihiro Ishiguro <[e-mail]>
Cc: [e-mail], "Naidu,     Venkata" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Fri, 21 Mar 2003 21:17:05 PST." <[e-mail]> 
Date: Sat, 22 Mar 2003 09:54:06 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Kunihiro Ishiguro writes:
> >Sitting on this until RPSEC develops requirements, and then solutions is not
> >an option.  Nor is moving the specification of a security mechanism out
> >of the draft.  In order to advance we must have a security mechanism 
> >specified.  MD5 is the winner by default.  It is widely deployed and
> >understood.
> 
> I want to say again we should be careful to specify BGP security
> consideration.  So far discussion is not technical other than Sandy's
> comment.
> 
> MUST is really must.  It enforce people to do it.  Just only for BGP,
> we should not enforce people to do TCP MD5.  There are many other (and
> better) way to do TCP authentication.
> 
> Again, specification is not only for endorsing big vendor's
> implementation.  We should be technical at here.
> -- 
> Kunihiro Ishiguro


We are not defining a new spec and moving it to PS.  We are reviewing
and correcting an old spec and moving it to FS.  In doing so we must
consider current implementations and current implementation
experience.  Pretty good new ideas that are sparsely implemented and
have near zero deployment have to be documented in other documents and
can *later* be moved into the base spec after they are widely
implemented and widely deployed.

Curtis



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA28975 for <[e-mail]>; Sat, 22 Mar 2003 02:20:29 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6CB6F9122B; Sat, 22 Mar 2003 02:20:05 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1155E91226; Sat, 22 Mar 2003 02:20:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B764C91228 for <[e-mail]>; Sat, 22 Mar 2003 02:20:02 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A2FDD5DDAB; Sat, 22 Mar 2003 02:20:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id 793FE5DD97 for <[e-mail]>; Sat, 22 Mar 2003 02:20:02 -0500 (EST)
Received: by nomad.tcb.net (Postfix, from userid 500) id 2F55C55FD4; Thu, 20 Mar 2003 19:14:02 -0700 (MST)
Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 2C75F3E83 for <[e-mail]>; Thu, 20 Mar 2003 19:14:02 -0700 (MST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: [e-mail]
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 20 Mar 2003 19:13:57 -0700
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I want to say again we should be careful to specify BGP security
> consideration. 

This issue with the MUST is that we MUST address security in order 
to progress the base BGP document and as Andrew says, TCP MD5 is the 
lowest common denominator.

> So far discussion is not technical other than Sandy's
> comment.
> 
> MUST is really must.  It enforce people to do it.  Just only for BGP,
> we should not enforce people to do TCP MD5.  There are many other (and
> better) way to do TCP authentication.

With the exception of a small amount of IPSEC, no other mechanism 
is deployed.

And RFCs don't "force" people to do things..  All of the implementations
that support TCP MD5 for BGP provide a mechanism to disable it, so if 
you're concerned with interworking you can either implement it or have
it disabled on the peer.  If you're worried about RFCNNNN rubber
stamping your implementation, well, I don't think the larger WG is.

> Again, specification is not only for endorsing big vendor's
> implementation.  We should be technical at here.

If we do anything beyond TCP MD5 right now then we'll the IDR WG
will be spinning our wheels for another 18 months, at a minimum.

As for RPSEC, we'll be quite a while generating a requirements list,
especially given the vast array of participants from purists & 
academics to realistics & operators, defining protocols that answer
the requirements and are either "bolted on" to BGP and other existing
protocols, or incorporated into new protocols, is a long, long, long 
time away.

-danny




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA24613 for <[e-mail]>; Sat, 22 Mar 2003 00:19:29 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 974D0912C9; Sat, 22 Mar 2003 00:19:09 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 346B8912C7; Sat, 22 Mar 2003 00:19:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B627912CB for <[e-mail]>; Sat, 22 Mar 2003 00:18:53 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6EDAC5DDA0; Sat, 22 Mar 2003 00:18:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (ip-64-139-11-202.dsl.sca.megapath.net [64.139.11.202]) by segue.merit.edu (Postfix) with ESMTP id B49C65DD9D for <[e-mail]>; Sat, 22 Mar 2003 00:18:52 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2M5H5Wr001107; Sat, 22 Mar 2003 14:17:05 +0900
Date: Fri, 21 Mar 2003 21:17:05 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: [e-mail]
Cc: "Naidu, Venkata" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: Issue 19) Security Considerations
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>Sitting on this until RPSEC develops requirements, and then solutions is not
>an option.  Nor is moving the specification of a security mechanism out
>of the draft.  In order to advance we must have a security mechanism 
>specified.  MD5 is the winner by default.  It is widely deployed and
>understood.

I want to say again we should be careful to specify BGP security
consideration.  So far discussion is not technical other than Sandy's
comment.

MUST is really must.  It enforce people to do it.  Just only for BGP,
we should not enforce people to do TCP MD5.  There are many other (and
better) way to do TCP authentication.

Again, specification is not only for endorsing big vendor's
implementation.  We should be technical at here.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA11732 for <[e-mail]>; Fri, 21 Mar 2003 18:06:12 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 24BEE912BA; Fri, 21 Mar 2003 18:05:52 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E987E912B9; Fri, 21 Mar 2003 18:05:51 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC792912BA for <[e-mail]>; Fri, 21 Mar 2003 18:05:48 -0500 (EST)
Received: by segue.merit.edu (Postfix) id BE1AF5E1C7; Fri, 21 Mar 2003 18:05:48 -0500 (EST)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 671165DD9C for <[e-mail]>; Fri, 21 Mar 2003 18:05:48 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id PAA07349; Fri, 21 Mar 2003 15:02:37 -0800 (PST)
Date: Fri, 21 Mar 2003 15:02:37 -0800
From: [e-mail]
To: Kunihiro Ishiguro <[e-mail]>
Cc: "Naidu, Venkata" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: Issue 19) Security Considerations
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Mar 21, 2003 at 02:32:34PM -0800
Sender: [e-mail]
Precedence: bulk

Sitting on this until RPSEC develops requirements, and then solutions is not
an option.  Nor is moving the specification of a security mechanism out
of the draft.  In order to advance we must have a security mechanism 
specified.  MD5 is the winner by default.  It is widely deployed and
understood.

If we want to later change things and issue a "Best Practices in BGP
Security" RFC we can, and should do that.

Andrew

On Fri, Mar 21, 2003 at 02:32:34PM -0800, Kunihiro Ishiguro wrote:
> Date: Fri, 21 Mar 2003 14:32:34 -0800
> From: Kunihiro Ishiguro <[e-mail]>
> To: "Naidu, Venkata" <[e-mail]>
> Cc: "'[e-mail]'" <[e-mail]>,
>    [e-mail], [e-mail]
> Subject: Re: Issue 19) Security Considerations 
> In-Reply-To: <[e-mail]>
> User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
> 
> >  We could mandate (using MUST) in the forthcoming BGP4
> >  spec, but, I suspect that, these MUSTs are going to 
> >  confuse people when RPSEC comes out with different  
> >  requirements in very near future.
> 
> I agree with it.  There must be a global picture for routing protocol
> security.
> -- 
> Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA10687 for <[e-mail]>; Fri, 21 Mar 2003 17:35:21 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9BE81912B4; Fri, 21 Mar 2003 17:34:43 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60D19912B0; Fri, 21 Mar 2003 17:34:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5CF7B912B8 for <[e-mail]>; Fri, 21 Mar 2003 17:34:03 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 437415E1C3; Fri, 21 Mar 2003 17:34:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (mail.ipinfusion.com [65.223.109.2]) by segue.merit.edu (Postfix) with ESMTP id C220C5E1BC for <[e-mail]>; Fri, 21 Mar 2003 17:34:02 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2LMWYG0002622; Sat, 22 Mar 2003 07:32:35 +0900
Date: Fri, 21 Mar 2003 14:32:34 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: "Naidu, Venkata" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-Reply-To: <[e-mail]>
References: <[e-mail]>
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>  We could mandate (using MUST) in the forthcoming BGP4
>  spec, but, I suspect that, these MUSTs are going to 
>  confuse people when RPSEC comes out with different  
>  requirements in very near future.

I agree with it.  There must be a global picture for routing protocol
security.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA10212 for <[e-mail]>; Fri, 21 Mar 2003 17:25:33 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6AA02912B3; Fri, 21 Mar 2003 17:25:08 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3423E912B0; Fri, 21 Mar 2003 17:25:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AEF5F912B3 for <[e-mail]>; Fri, 21 Mar 2003 17:25:06 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 94B5B5E1AF; Fri, 21 Mar 2003 17:25:06 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (mail.ipinfusion.com [65.223.109.2]) by segue.merit.edu (Postfix) with ESMTP id 1DCAD5DDB1 for <[e-mail]>; Fri, 21 Mar 2003 17:25:06 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2LMNgG0002583; Sat, 22 Mar 2003 07:23:42 +0900
Date: Fri, 21 Mar 2003 14:23:42 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>It is a legitimate question whether current tier-1 deployments should
>entirely drive the spec in this area.  If the answer is "no" then
>perhaps the requirement for TCP MD5 could be loosenned a little.

I believe BGP protocol is not only for tier-1 deployments.  BGP is
used from very small network to large network in various kind of
situation today.  For example countless RFC2547bis CE client connect
to PE using BGP for VPN services.

Again BGP is not only for tier-1 network based upon Cisco and Juniper
today.  There are so many other situations.

BGP security consideration is very important issue.  Just making TCP
MD5 MUST does not solve the problem.  I still suggest to separate this
issue from base BGP spec.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA09971 for <[e-mail]>; Fri, 21 Mar 2003 17:19:17 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id F341A91360; Fri, 21 Mar 2003 17:12:17 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6DB99134E; Fri, 21 Mar 2003 17:12:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D90191328 for <[e-mail]>; Fri, 21 Mar 2003 17:06:24 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 370815E1AF; Fri, 21 Mar 2003 17:06:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id B7E535E1BA for <[e-mail]>; Fri, 21 Mar 2003 17:06:23 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA15013; Fri, 21 Mar 2003 17:06:20 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA24892; Fri, 21 Mar 2003 17:06:22 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <HMVY0QTH>; Fri, 21 Mar 2003 17:06:22 -0500
Message-ID: <[e-mail]>
From: "Naidu, Venkata" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Kunihiro Ishiguro <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Issue 19) Security Considerations 
Date: Fri, 21 Mar 2003 17:06:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Curtis,

-> There is currently no evidence that I can see of a
-> transition from TCP MD5 to IPSEC.  

  Let us not mandate anything specific to routing security.
  RPSEC WG is specifically formed to clear all these 
  confusions to make a common ground for all the 
  routing protocols (esp router-to-router, not host-to-
  router).

  RPSEC charter reads:
    . . .
    The lack of a common set of security requirements and 
    methods for routing protocols has resulted in a wide 
    variety of security mechanisms for individual routing 
    protocols. 
    . . .
    Evaluate and document existing and proposed routing 
    security mechanisms with respect to established RPSEC 
    requirements 
    . . .
    Recommend mechanism(s) 
    . . .

  We could mandate (using MUST) in the forthcoming BGP4
  spec, but, I suspect that, these MUSTs are going to 
  confuse people when RPSEC comes out with different  
  requirements in very near future.

Venkata.


Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA09899 for <[e-mail]>; Fri, 21 Mar 2003 17:17:05 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 69E849137F; Fri, 21 Mar 2003 17:12:11 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0824A912F5; Fri, 21 Mar 2003 17:12:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AA7C791362 for <[e-mail]>; Fri, 21 Mar 2003 17:09:00 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8D51C5E1AF; Fri, 21 Mar 2003 17:09:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 03E725E1BA for <[e-mail]>; Fri, 21 Mar 2003 17:09:00 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id OAA06663; Fri, 21 Mar 2003 14:05:59 -0800 (PST)
Date: Fri, 21 Mar 2003 14:05:59 -0800
From: [e-mail]
To: Kunihiro Ishiguro <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Mar 21, 2003 at 01:11:29PM -0800
Sender: [e-mail]
Precedence: bulk

I would suggest we leave the MUST simply from an interoperabilty standpoint.
We want to have a lowest common authentication denominator that all 
implementations do, so, at a minimum they will interopreate.  If the
implementation wants to implement IPSEC too, then great.  But since
MD5 is currently widely deployed, it makes more sense as the lowest common
denominator.

Andrew

On Fri, Mar 21, 2003 at 01:11:29PM -0800, Kunihiro Ishiguro wrote:
> Date: Fri, 21 Mar 2003 13:11:29 -0800
> From: Kunihiro Ishiguro <[e-mail]>
> To: [e-mail]
> Cc: [e-mail], [e-mail]
> Subject: Re: Issue 19) Security Considerations 
> In-Reply-To: <[e-mail]>
> User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
> 
> >I suggest that we leave the MUST in there because it reflects current
> >implementation and deployments and is not considered optional by any
> >of the ISPs.  The word MUST sends exactly the message it was intended
> >to send.
> 
> Actually there are so many box which does not support TCP MD5.  I know
> it becuase I believe I'm one of BGP protocol implementator ;-).
> 
> When BGP base specificatoin claim that TCP MD5 is MUST item,
> implementors has to implement TCP MD5 only for BGP.  Even there are
> alternative way to achieve security.
> 
> I understand we are working on current best practice but at the same
> time it has strong influence to future development.  I think we should
> be careful to put TCP MD5 as MUST in base specification.  In the long
> run it could be wrong message.
> -- 
> Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA08887 for <[e-mail]>; Fri, 21 Mar 2003 16:49:59 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 462AC912D2; Fri, 21 Mar 2003 16:45:05 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B55A7912B4; Fri, 21 Mar 2003 16:45:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7B32A912D2 for <[e-mail]>; Fri, 21 Mar 2003 16:41:12 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 273705E1AF; Fri, 21 Mar 2003 16:41:12 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 5B2CA5DFD4 for <[e-mail]>; Fri, 21 Mar 2003 16:41:11 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id QAA79016; Fri, 21 Mar 2003 16:38:31 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kunihiro Ishiguro <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Fri, 21 Mar 2003 13:11:29 PST." <[e-mail]> 
Date: Fri, 21 Mar 2003 16:38:31 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Kunihiro Ishiguro writes:
> >I suggest that we leave the MUST in there because it reflects current
> >implementation and deployments and is not considered optional by any
> >of the ISPs.  The word MUST sends exactly the message it was intended
> >to send.
> 
> Actually there are so many box which does not support TCP MD5.  I know
> it becuase I believe I'm one of BGP protocol implementator ;-).

I'm familiar with zebra.  It is not deployed except as a toy on some
unix boxes and some wannabe routers.  That may not be a reflection on
the quality of the work, however zebra does not reflect the
requirements of fitting into current tier-1 ISP deployments.

It is a legitimate question whether current tier-1 deployments should
entirely drive the spec in this area.  If the answer is "no" then
perhaps the requirement for TCP MD5 could be loosenned a little.

> When BGP base specificatoin claim that TCP MD5 is MUST item,
> implementors has to implement TCP MD5 only for BGP.  Even there are
> alternative way to achieve security.
> 
> I understand we are working on current best practice but at the same
> time it has strong influence to future development.  I think we should
> be careful to put TCP MD5 as MUST in base specification.  In the long
> run it could be wrong message.
> -- 
> Kunihiro Ishiguro

TCP MD5 is currently considered by ISPs to be an operation
requirement.  There is currently no evidence that I can see of a
transition from TCP MD5 to IPSEC.  At the most we can change the
wording to indicate that for security reasons as a practical matter
TCP MD5 currently MUST be implemented however IPSEC represents a
technical alternative in the future that has so far seen little or no
deployment as protection for BGP.

Curtis



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA07613 for <[e-mail]>; Fri, 21 Mar 2003 16:13:26 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 13080912AC; Fri, 21 Mar 2003 16:13:06 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4A89912AB; Fri, 21 Mar 2003 16:13:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A237C912AC for <[e-mail]>; Fri, 21 Mar 2003 16:13:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 894845E1A7; Fri, 21 Mar 2003 16:13:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (mail.ipinfusion.com [65.223.109.2]) by segue.merit.edu (Postfix) with ESMTP id 14BF95E1A2 for <[e-mail]>; Fri, 21 Mar 2003 16:13:04 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2LLBTG0002302; Sat, 22 Mar 2003 06:11:29 +0900
Date: Fri, 21 Mar 2003 13:11:29 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>I suggest that we leave the MUST in there because it reflects current
>implementation and deployments and is not considered optional by any
>of the ISPs.  The word MUST sends exactly the message it was intended
>to send.

Actually there are so many box which does not support TCP MD5.  I know
it becuase I believe I'm one of BGP protocol implementator ;-).

When BGP base specificatoin claim that TCP MD5 is MUST item,
implementors has to implement TCP MD5 only for BGP.  Even there are
alternative way to achieve security.

I understand we are working on current best practice but at the same
time it has strong influence to future development.  I think we should
be careful to put TCP MD5 as MUST in base specification.  In the long
run it could be wrong message.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07110 for <[e-mail]>; Fri, 21 Mar 2003 15:59:33 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 03D69912A9; Fri, 21 Mar 2003 15:59:06 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B64A0912AC; Fri, 21 Mar 2003 15:59:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 50072912A9 for <[e-mail]>; Fri, 21 Mar 2003 15:59:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3F40A5DFB7; Fri, 21 Mar 2003 15:59:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 60FB45DEC8 for <[e-mail]>; Fri, 21 Mar 2003 15:59:03 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id PAA77561; Fri, 21 Mar 2003 15:56:24 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kunihiro Ishiguro <[e-mail]>
Cc: [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Fri, 21 Mar 2003 12:26:13 PST." <[e-mail]> 
Date: Fri, 21 Mar 2003 15:56:24 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Kunihiro Ishiguro writes:
> >Since there is no standard specifying BGP over IPSEC, we should leave this
> >out of the base draft.  I know there has been work in this area, I believe
> >Dave Ward has/had a draft.  I can only find the withdrawn id info now, thoug
> h.
> >
> >I would suggest that we leave this out of the base draft, and if we 
> >later specify IPSEC, then we should add it in that draft. 
> 
> Thanks for comment.  I think we shold take the security concern out of
> the base draft and specify it separately.
> 
> You know MUST item in specification has strong power.  Before we put
> TCP MD5 as only one MUST item in security concern section in BGP we
> need to think about it.  It seems we have a plan to refer other draft
> as detailed security considerations right?  Then I'd like to put
> security concern into the draft.
> -- 
> Kunihiro Ishiguro


I suggest that we leave the MUST in there because it reflects current
implementation and deployments and is not considered optional by any
of the ISPs.  The word MUST sends exactly the message it was intended
to send.

Curtis



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA06047 for <[e-mail]>; Fri, 21 Mar 2003 15:27:55 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4A0E3912AA; Fri, 21 Mar 2003 15:27:36 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D2C4912AD; Fri, 21 Mar 2003 15:27:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A024B912AA for <[e-mail]>; Fri, 21 Mar 2003 15:27:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9023A5E047; Fri, 21 Mar 2003 15:27:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (mail.ipinfusion.com [65.223.109.2]) by segue.merit.edu (Postfix) with ESMTP id 1A0395DEA9 for <[e-mail]>; Fri, 21 Mar 2003 15:27:34 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2LKQDG0002117; Sat, 22 Mar 2003 05:26:13 +0900
Date: Fri, 21 Mar 2003 12:26:13 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations
In-Reply-To: <[e-mail]>
References: <[e-mail]>
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>Since there is no standard specifying BGP over IPSEC, we should leave this
>out of the base draft.  I know there has been work in this area, I believe
>Dave Ward has/had a draft.  I can only find the withdrawn id info now, though.
>
>I would suggest that we leave this out of the base draft, and if we 
>later specify IPSEC, then we should add it in that draft. 

Thanks for comment.  I think we shold take the security concern out of
the base draft and specify it separately.

You know MUST item in specification has strong power.  Before we put
TCP MD5 as only one MUST item in security concern section in BGP we
need to think about it.  It seems we have a plan to refer other draft
as detailed security considerations right?  Then I'd like to put
security concern into the draft.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA03602 for <[e-mail]>; Fri, 21 Mar 2003 14:19:19 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1800B912A2; Fri, 21 Mar 2003 14:18:49 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFC79912A9; Fri, 21 Mar 2003 14:18:48 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED01F912A2 for <[e-mail]>; Fri, 21 Mar 2003 14:18:46 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D13875DE79; Fri, 21 Mar 2003 14:18:46 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 91D425E08E for <[e-mail]>; Fri, 21 Mar 2003 14:18:45 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA75924; Fri, 21 Mar 2003 14:16:06 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: Curtis Villamizar <[e-mail]>, [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Fri, 21 Mar 2003 11:04:33 PST." <[e-mail]> 
Date: Fri, 21 Mar 2003 14:16:06 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Off topic a little, but worth mentioning.

The *real* problems that ISPs find themselves facing cannot be solved
by the better encryption of IPSEC.  IPSEC does nothing to improve the
DoS threat that is real, but does address what is considered by most
ISPs to be currently a complete non-problem due to filtering
techniques that have been in place for years.

Please see <http://www.nanog.org/mtg-0302/hack.html>,
<http://www.nanog.org/mtg-0302/gill.html>, and draft-gill-btsh-01.txt.

Its best to understand the problems before proposing the solutions.

Curtis


In message <[e-mail]>, [e-mail]
dus.net writes:
> I think Curits has nailed it down nicely.  I used the "standardize" statement
> a bit more loosely than I should have, perhaps.  As a practical matter, if
> we want people to make IPSec a consistantly implemented and deployed option 
> we, as a community, will need to bless it by publishing some sort of document
> .
> 
> Andrew
> 
> On Fri, Mar 21, 2003 at 11:41:05AM -0500, Curtis Villamizar wrote:
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > To: [e-mail]
> > Cc: [e-mail], [e-mail], [e-mail],
> >    [e-mail]
> > Reply-To: [e-mail]
> > Subject: Re: Issue 19) Security Considerations 
> > In-reply-to: Your message of "Fri, 21 Mar 2003 11:31:32 EST."
> >              <[e-mail]> 
> > Date: Fri, 21 Mar 2003 11:41:05 -0500
> > From: Curtis Villamizar <[e-mail]>
> > Precedence: bulk
> > X-Spam-Status: No, hits=-0.8 required=5
> > X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
> > X-OriginalArrivalTime: 21 Mar 2003 16:43:53.0710 (UTC) FILETIME=[0EE440E0:0
> 1C2EFC9]
> > 
> > 
> > In message <[e-mail]>, sandy@tislabs.
> com 
> > writes:
> > > >You are missing that the BGP4 spec must reflect current practice and
> > > >may point out better than current practice if such a thing is
> > > >currently defined.  BGP over IPSEC is not currently defined, therefore
> > > >the BGP4 spec neither advocates it or prevents it.
> > > 
> > > Oh, yes.  I know the guidelines for including things in the current
> > > spec.  I was just trying to understand Andrew's comment and why he
> > > thought there would have to be a standard for running BGP over IPSEC
> > > before it could be included in the base spec.  I thought there was an
> > > implication that there would be issues to work out in doing that
> > > (especially since he referred to an old work that defined how to do it).
> > > Same implication in your comment "BGP over IPSEC is not currently defined
> "
> > > - what's to define?
> > > 
> > > With the current focus on documenting current practice, if current
> > > practice does not include running BGP over IPSEC, then we cannot put
> > > it in the draft, whether it needed defining or standardization or not.
> > > So my question is academic or for future reference.
> > > 
> > > --Sandy
> > 
> > 
> > No technical issue, just can't refer to a spec that doesn't yet exist
> > when trying to go for FS (or PS for that matter).
> > 
> > Add to that the IDR WG is not supposed to work on anything new (or
> > more correctly take on WG items or try to advance anything new) until
> > the base BGP4 spec gets updated.
> > 
> > As soon as BGP4-(N->infinity) is at least out of WG last call advanced
> > to the IESG this is one of the internet-drafts that could (should IMO)
> > be considered by the WG.
> > 
> > Curtis
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA03274 for <[e-mail]>; Fri, 21 Mar 2003 14:08:40 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 64C51912A8; Fri, 21 Mar 2003 14:08:03 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C205912A9; Fri, 21 Mar 2003 14:08:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D3AB7912A7 for <[e-mail]>; Fri, 21 Mar 2003 14:08:00 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B3DC95E18A; Fri, 21 Mar 2003 14:08:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 5CF6B5E186 for <[e-mail]>; Fri, 21 Mar 2003 14:08:00 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id LAA04488; Fri, 21 Mar 2003 11:04:33 -0800 (PST)
Date: Fri, 21 Mar 2003 11:04:33 -0800
From: [e-mail]
To: Curtis Villamizar <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Mar 21, 2003 at 11:41:05AM -0500
Sender: [e-mail]
Precedence: bulk

I think Curits has nailed it down nicely.  I used the "standardize" statement
a bit more loosely than I should have, perhaps.  As a practical matter, if
we want people to make IPSec a consistantly implemented and deployed option 
we, as a community, will need to bless it by publishing some sort of document.

Andrew

On Fri, Mar 21, 2003 at 11:41:05AM -0500, Curtis Villamizar wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> To: [e-mail]
> Cc: [e-mail], [e-mail], [e-mail],
>    [e-mail]
> Reply-To: [e-mail]
> Subject: Re: Issue 19) Security Considerations 
> In-reply-to: Your message of "Fri, 21 Mar 2003 11:31:32 EST."
>              <[e-mail]> 
> Date: Fri, 21 Mar 2003 11:41:05 -0500
> From: Curtis Villamizar <[e-mail]>
> Precedence: bulk
> X-Spam-Status: No, hits=-0.8 required=5
> X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
> X-OriginalArrivalTime: 21 Mar 2003 16:43:53.0710 (UTC) FILETIME=[0EE440E0:01C2EFC9]
> 
> 
> In message <[e-mail]>, [e-mail] 
> writes:
> > >You are missing that the BGP4 spec must reflect current practice and
> > >may point out better than current practice if such a thing is
> > >currently defined.  BGP over IPSEC is not currently defined, therefore
> > >the BGP4 spec neither advocates it or prevents it.
> > 
> > Oh, yes.  I know the guidelines for including things in the current
> > spec.  I was just trying to understand Andrew's comment and why he
> > thought there would have to be a standard for running BGP over IPSEC
> > before it could be included in the base spec.  I thought there was an
> > implication that there would be issues to work out in doing that
> > (especially since he referred to an old work that defined how to do it).
> > Same implication in your comment "BGP over IPSEC is not currently defined"
> > - what's to define?
> > 
> > With the current focus on documenting current practice, if current
> > practice does not include running BGP over IPSEC, then we cannot put
> > it in the draft, whether it needed defining or standardization or not.
> > So my question is academic or for future reference.
> > 
> > --Sandy
> 
> 
> No technical issue, just can't refer to a spec that doesn't yet exist
> when trying to go for FS (or PS for that matter).
> 
> Add to that the IDR WG is not supposed to work on anything new (or
> more correctly take on WG items or try to advance anything new) until
> the base BGP4 spec gets updated.
> 
> As soon as BGP4-(N->infinity) is at least out of WG last call advanced
> to the IESG this is one of the internet-drafts that could (should IMO)
> be considered by the WG.
> 
> Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27803 for <[e-mail]>; Fri, 21 Mar 2003 11:44:06 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9FB6291294; Fri, 21 Mar 2003 11:43:44 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 672359129E; Fri, 21 Mar 2003 11:43:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2679091294 for <[e-mail]>; Fri, 21 Mar 2003 11:43:43 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0B9EA5E058; Fri, 21 Mar 2003 11:43:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 4A2FE5DF64 for <[e-mail]>; Fri, 21 Mar 2003 11:43:42 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA74009; Fri, 21 Mar 2003 11:41:06 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Fri, 21 Mar 2003 11:31:32 EST." <[e-mail]> 
Date: Fri, 21 Mar 2003 11:41:05 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, [e-mail] 
writes:
> >You are missing that the BGP4 spec must reflect current practice and
> >may point out better than current practice if such a thing is
> >currently defined.  BGP over IPSEC is not currently defined, therefore
> >the BGP4 spec neither advocates it or prevents it.
> 
> Oh, yes.  I know the guidelines for including things in the current
> spec.  I was just trying to understand Andrew's comment and why he
> thought there would have to be a standard for running BGP over IPSEC
> before it could be included in the base spec.  I thought there was an
> implication that there would be issues to work out in doing that
> (especially since he referred to an old work that defined how to do it).
> Same implication in your comment "BGP over IPSEC is not currently defined"
> - what's to define?
> 
> With the current focus on documenting current practice, if current
> practice does not include running BGP over IPSEC, then we cannot put
> it in the draft, whether it needed defining or standardization or not.
> So my question is academic or for future reference.
> 
> --Sandy


No technical issue, just can't refer to a spec that doesn't yet exist
when trying to go for FS (or PS for that matter).

Add to that the IDR WG is not supposed to work on anything new (or
more correctly take on WG items or try to advance anything new) until
the base BGP4 spec gets updated.

As soon as BGP4-(N->infinity) is at least out of WG last call advanced
to the IESG this is one of the internet-drafts that could (should IMO)
be considered by the WG.

Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27431 for <[e-mail]>; Fri, 21 Mar 2003 11:33:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 05B1E9129B; Fri, 21 Mar 2003 11:33:23 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8470A9129D; Fri, 21 Mar 2003 11:33:22 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF62A9129B for <[e-mail]>; Fri, 21 Mar 2003 11:32:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C85FA5DF64; Fri, 21 Mar 2003 11:32:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 5552C5E06C for <[e-mail]>; Fri, 21 Mar 2003 11:32:05 -0500 (EST)
Received: by sentry.gw.tislabs.com; id LAA20010; Fri, 21 Mar 2003 11:32:59 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma019997; Fri, 21 Mar 03 11:32:28 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2LGVWX12902; Fri, 21 Mar 2003 11:31:32 -0500 (EST)
Date: Fri, 21 Mar 2003 11:31:32 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

>You are missing that the BGP4 spec must reflect current practice and
>may point out better than current practice if such a thing is
>currently defined.  BGP over IPSEC is not currently defined, therefore
>the BGP4 spec neither advocates it or prevents it.

Oh, yes.  I know the guidelines for including things in the current
spec.  I was just trying to understand Andrew's comment and why he
thought there would have to be a standard for running BGP over IPSEC
before it could be included in the base spec.  I thought there was an
implication that there would be issues to work out in doing that
(especially since he referred to an old work that defined how to do it).
Same implication in your comment "BGP over IPSEC is not currently defined"
- what's to define?

With the current focus on documenting current practice, if current
practice does not include running BGP over IPSEC, then we cannot put
it in the draft, whether it needed defining or standardization or not.
So my question is academic or for future reference.

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA26741 for <[e-mail]>; Fri, 21 Mar 2003 11:12:38 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D4DBC9120D; Fri, 21 Mar 2003 11:12:20 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0A9B91294; Fri, 21 Mar 2003 11:12:20 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63BBE9120D for <[e-mail]>; Fri, 21 Mar 2003 11:12:19 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 4FD8E5E074; Fri, 21 Mar 2003 11:12:19 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 70B2C5E060 for <[e-mail]>; Fri, 21 Mar 2003 11:12:18 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA73593; Fri, 21 Mar 2003 11:09:18 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 19) Security Considerations 
In-reply-to: Your message of "Fri, 21 Mar 2003 08:19:39 EST." <[e-mail]> 
Date: Fri, 21 Mar 2003 11:09:18 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, [e-mail] 
writes:
> >Since there is no standard specifying BGP over IPSEC,
> 
> I'm not sure I understand this comment.  Could you explain?
> 
> The spec for using TCP MD5 is entitled "Protection of BGP Sessions
> via the TCP MD5 Signature (sic) Option" but the mechanism described really
> has no relationship to BGP.  It's just a mechanism for doing authentication
> at the TCP level.  You could use the same draft to protect any other
> TCP application (but please don't - TLS or IPSEC would be better).
> 
> The BGP draft says "go do that".
> 
> The BGP draft could just as easily say "go do IPSEC" - I don't see that
> there would be anything left to standardize that would require a BGP over
> IPSEC document.
> 
> Am I missing something?
> 
> --Sandy


You are missing that the BGP4 spec must reflect current practice and
may point out better than current practice if such a thing is
currently defined.  BGP over IPSEC is not currently defined, therefore
the BGP4 spec neither advocates it or prevents it.

Curtis



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA19138 for <[e-mail]>; Fri, 21 Mar 2003 08:20:51 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 86EE391298; Fri, 21 Mar 2003 08:20:28 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6090C91294; Fri, 21 Mar 2003 08:20:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 85AA29120D for <[e-mail]>; Fri, 21 Mar 2003 08:20:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 69B275E101; Fri, 21 Mar 2003 08:20:26 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id ED4FE5E0EB for <[e-mail]>; Fri, 21 Mar 2003 08:20:25 -0500 (EST)
Received: by sentry.gw.tislabs.com; id IAA15219; Fri, 21 Mar 2003 08:21:19 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma015201; Fri, 21 Mar 03 08:20:34 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id h2LDJdb02987; Fri, 21 Mar 2003 08:19:39 -0500 (EST)
Date: Fri, 21 Mar 2003 08:19:39 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail]
Subject: Re: Issue 19) Security Considerations
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

>Since there is no standard specifying BGP over IPSEC,

I'm not sure I understand this comment.  Could you explain?

The spec for using TCP MD5 is entitled "Protection of BGP Sessions
via the TCP MD5 Signature (sic) Option" but the mechanism described really
has no relationship to BGP.  It's just a mechanism for doing authentication
at the TCP level.  You could use the same draft to protect any other
TCP application (but please don't - TLS or IPSEC would be better).

The BGP draft says "go do that".

The BGP draft could just as easily say "go do IPSEC" - I don't see that
there would be anything left to standardize that would require a BGP over
IPSEC document.

Am I missing something?

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA02782 for <[e-mail]>; Fri, 21 Mar 2003 00:20:48 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 077449128F; Fri, 21 Mar 2003 00:20:26 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C920191291; Fri, 21 Mar 2003 00:20:25 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CFB639128F for <[e-mail]>; Fri, 21 Mar 2003 00:20:24 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B16A65DEBA; Fri, 21 Mar 2003 00:20:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 5B9685DE81 for <[e-mail]>; Fri, 21 Mar 2003 00:20:24 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id VAA24542; Thu, 20 Mar 2003 21:17:25 -0800 (PST)
Date: Thu, 20 Mar 2003 21:17:25 -0800
From: [e-mail]
To: Kunihiro Ishiguro <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 19) Security Considerations
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Mar 20, 2003 at 09:01:40PM -0800
Sender: [e-mail]
Precedence: bulk

Since there is no standard specifying BGP over IPSEC, we should leave this
out of the base draft.  I know there has been work in this area, I believe
Dave Ward has/had a draft.  I can only find the withdrawn id info now, though.

I would suggest that we leave this out of the base draft, and if we 
later specify IPSEC, then we should add it in that draft. 

Andrew


On Thu, Mar 20, 2003 at 09:01:40PM -0800, Kunihiro Ishiguro wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Date: Thu, 20 Mar 2003 21:01:40 -0800
> From: Kunihiro Ishiguro <[e-mail]>
> To: [e-mail]
> Subject: Issue 19) Security Considerations
> User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
> Precedence: bulk
> X-Spam-Status: No, hits=-0.8 required=5
> X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang)
> X-OriginalArrivalTime: 21 Mar 2003 05:05:49.0351 (UTC) FILETIME=[89DE4370:01C2EF67]
> 
> >      Use of TCP MD5 [RFC2385] for authentication is mandatory.
> 
> Sorry for late comment.  When router has IPsec, the box can do TCP
> authentication (IMHO IPsec is better than TCP MD5).  I'd like to
> suggest to add a choice of IPsec not only TCP MD5.
> -- 
> Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA02271 for <[e-mail]>; Fri, 21 Mar 2003 00:06:02 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7F51091296; Fri, 21 Mar 2003 00:05:36 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3882F91292; Fri, 21 Mar 2003 00:05:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 38E1491293 for <[e-mail]>; Fri, 21 Mar 2003 00:03:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1D79D5DEAC; Fri, 21 Mar 2003 00:03:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from localhost.localdomain (ip-64-139-11-202.dsl.sca.megapath.net [64.139.11.202]) by segue.merit.edu (Postfix) with ESMTP id 3AED85DDC9 for <[e-mail]>; Fri, 21 Mar 2003 00:03:04 -0500 (EST)
Received: from localhost.localdomain (vprmatrix [127.0.0.1]) by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h2L51eIK001185 for <[e-mail]>; Fri, 21 Mar 2003 14:01:43 +0900
Date: Thu, 20 Mar 2003 21:01:40 -0800
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: [e-mail]
Subject: Issue 19) Security Considerations
User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.92 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>      Use of TCP MD5 [RFC2385] for authentication is mandatory.

Sorry for late comment.  When router has IPsec, the box can do TCP
authentication (IMHO IPsec is better than TCP MD5).  I'd like to
suggest to add a choice of IPsec not only TCP MD5.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA20536 for <[e-mail]>; Thu, 20 Mar 2003 18:34:44 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 23DE191295; Thu, 20 Mar 2003 18:34:13 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DCD091290; Thu, 20 Mar 2003 18:34:12 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 057A191295 for <[e-mail]>; Thu, 20 Mar 2003 18:34:08 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 10D315E1B1; Thu, 20 Mar 2003 18:34:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id AD3135E1AD for <[e-mail]>; Thu, 20 Mar 2003 18:34:07 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2KNY2iC001339; Thu, 20 Mar 2003 18:34:02 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2KNXxNp001332; Thu, 20 Mar 2003 18:33:59 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2KNXsK23429; Thu, 20 Mar 2003 18:33:54 -0500 (EST)
Date: Thu, 20 Mar 2003 18:33:54 -0500
From: Jeffrey Haas <[e-mail]>
To: Bruno Rijsman <[e-mail]>
Cc: [e-mail]
Subject: Re: questions about the index of the bgpM2PeerTable
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Mar 20, 2003 at 10:34:07AM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Bruno,

On Thu, Mar 20, 2003 at 10:34:07AM -0500, Bruno Rijsman wrote:
> I have some questions about the index of the bgpM2PeerTable in
> draft-ietf-idr-bgp4-mibv2-03.txt:
> 
> >bgpM2PeerEntry OBJECT-TYPE
> >     ...
> >     INDEX {
> >         bgpM2PeerLocalAddrType,
> >         bgpM2PeerLocalAddr,
> >         bgpM2PeerRemoteAddrType,
> >         bgpM2PeerRemoteAddr
> >     }
> 
[out of order]
> Also, as far as I know, existing implementations do not allow you
> to configure two BGP sessions to the same remote address with
> different local addresses.

Where the lack of existing implementations that do this is true,
I don't believe the specification precludes this.  Please note the
connection collsion text in 6.8, first paragraph.  This paragraph
doesn't explicitly declare this as a feature, but the comparison
implies that it could happen.

A potentially valid example is maintaining two peering sessions
across different interfaces to the same host.

[...]

> The local address of a BGP session may not be known until the
> session comes up (and as a side-effect, if the session bounces
> it may end up with a different local address the second the the
> session comes up). This might happen, for example, if the session
> is an IBGP session or a multihop EBGP session without a configured
> update-source address.

This is a good example of where this might be an issue.  Do you have
any suggested workarounds?

My own thought is that in the case where the source address is not
known ahead of time that a value of 0.0.0.0 (or all zeros for a given
addrtype) would mean that its an unspecified address on configuration.
It may be ok to leave this in the established state as well to
make the tables queryable.  The implementations I have worked with
tend to require you to specify the local end of the connection
via configuration in some cases and when this is done, the value can
be placed here.

> In RFC 2547 style VPNs, there may be several peers with the
> same remote (and local) address because each VRF has its own address
> space. Should we say that this table does not contain entries for
> PE-CE sessions? Or, alternatively, should we add some identification
> of the VRF in the index?

This is a valid concern and worthy of some thought.

Consider bgpM2NlriIndex which does something similar for the 
path attributes table.

> >bgpM2PeerIndex OBJECT-TYPE
> >...
> >Values in the
> >bgpM2PeerTable and other tables utilizing bgpM2PeerIndex
> >are expected to remain in existence for an arbitrary
> >time after the unconfigured peer has been deleted
> >in order to allow management applications to extract
> >useful management information for those peers.
> 
> Does this mean that if we create 1,000 peers and then remove
> those 1,000 peers, the bgpM2PeerTable has to continue to contain
> rows for those 1,000 removed peers for ever?

This is up to the implementation.

> Even across reloads?

This is also up to the implmentation. :-)

> That seems a very harsh requirement on the BGP implementation to
> keep all this information around about peers that used to exist
> in some distant past... Would it be possible to remove that
> requirement?

Since the bgpM2PeerIndex is referred to by other tables, the idea
is that you want to be able to get data that may otherwise
disapear out from under it.  Requiring it forever is unreasonable.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA03839 for <[e-mail]>; Thu, 20 Mar 2003 10:34:35 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D022A9127D; Thu, 20 Mar 2003 10:34:11 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 737A29121C; Thu, 20 Mar 2003 10:34:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 607A69127C for <[e-mail]>; Thu, 20 Mar 2003 10:34:09 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 42FA25E114; Thu, 20 Mar 2003 10:34:09 -0500 (EST)
Delivered-To: [e-mail]
Received: from hotmail.com (bay1-f159.bay1.hotmail.com [65.54.245.159]) by segue.merit.edu (Postfix) with ESMTP id 814585E0FF for <[e-mail]>; Thu, 20 Mar 2003 10:34:07 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 Mar 2003 07:34:07 -0800
Received: from 65.194.140.2 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 20 Mar 2003 15:34:07 GMT
X-Originating-IP: [65.194.140.2]
X-Originating-Email: [[e-mail]]
From: "Bruno Rijsman" <[e-mail]>
To: [e-mail]
Subject: questions about the index of the bgpM2PeerTable
Date: Thu, 20 Mar 2003 10:34:07 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 20 Mar 2003 15:34:07.0979 (UTC) FILETIME=[2596A3B0:01C2EEF6]
Sender: [e-mail]
Precedence: bulk

I have some questions about the index of the bgpM2PeerTable in
draft-ietf-idr-bgp4-mibv2-03.txt:

>bgpM2PeerEntry OBJECT-TYPE
>     ...
>     INDEX {
>         bgpM2PeerLocalAddrType,
>         bgpM2PeerLocalAddr,
>         bgpM2PeerRemoteAddrType,
>         bgpM2PeerRemoteAddr
>     }

The local address of a BGP session may not be known until the
session comes up (and as a side-effect, if the session bounces
it may end up with a different local address the second the the
session comes up). This might happen, for example, if the session
is an IBGP session or a multihop EBGP session without a configured
update-source address.

Also, as far as I know, existing implementations do not allow you
to configure two BGP sessions to the same remote address with
different local addresses.

Given that, would it make sense to remove the local address
from the index?

In RFC 2547 style VPNs, there may be several peers with the
same remote (and local) address because each VRF has its own address
space. Should we say that this table does not contain entries for
PE-CE sessions? Or, alternatively, should we add some identification
of the VRF in the index?

>bgpM2PeerIndex OBJECT-TYPE
>...
>Values in the
>bgpM2PeerTable and other tables utilizing bgpM2PeerIndex
>are expected to remain in existence for an arbitrary
>time after the unconfigured peer has been deleted
>in order to allow management applications to extract
>useful management information for those peers.

Does this mean that if we create 1,000 peers and then remove
those 1,000 peers, the bgpM2PeerTable has to continue to contain
rows for those 1,000 removed peers for ever? Even across reloads?
That seems a very harsh requirement on the BGP implementation to
keep all this information around about peers that used to exist
in some distant past... Would it be possible to remove that
requirement?



_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA13815 for <[e-mail]>; Mon, 17 Mar 2003 17:53:28 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9FD5991218; Mon, 17 Mar 2003 17:53:10 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 639279121F; Mon, 17 Mar 2003 17:53:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98CC191218 for <[e-mail]>; Mon, 17 Mar 2003 17:53:08 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 855345DF22; Mon, 17 Mar 2003 17:53:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from hotmail.com (bay1-f157.bay1.hotmail.com [65.54.245.157]) by segue.merit.edu (Postfix) with ESMTP id 40E955DE2B for <[e-mail]>; Mon, 17 Mar 2003 17:53:08 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Mar 2003 14:53:07 -0800
Received: from 65.194.140.2 by by1fd.bay1.hotmail.msn.com with HTTP; Mon, 17 Mar 2003 22:53:07 GMT
X-Originating-IP: [65.194.140.2]
From: "Bruno Rijsman" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: bgpM2CfgConfederationRouter in BGP4-V2-MIB
Date: Mon, 17 Mar 2003 17:53:07 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 17 Mar 2003 22:53:07.0757 (UTC) FILETIME=[FA148DD0:01C2ECD7]
Sender: [e-mail]
Precedence: bulk

Do we really need the read-write object bgpM2CfgConfederationRouter in
BGP4-V2-MIB? Setting this object to false to "make the implementation
not support confederations" doesn't seem to make much sense.

Note that "the implementation does not support confederations" is
something different from "the BGP speaker is not a confederation router"
which does make sense and which is achieved by setting
bgpM2CfgConfederationId to zero.

Relevant snippet from BGP4-V2-MIB:

    bgpM2CfgConfederationRouter OBJECT-TYPE
        SYNTAX     TruthValue
        MAX-ACCESS read-write
        STATUS     current
        DESCRIPTION
            "This value is set to true if this implementation will be
             supporting BGP AS Confederations."
        REFERENCE
            "RFC 3065 - Autonomous System Confederations for BGP"
        ::= { bgpM2CfgBaseScalarASConfedExts 1 }

    bgpM2CfgConfederationId OBJECT-TYPE
        SYNTAX     InetAutonomousSystemNumber
        MAX-ACCESS read-write
        STATUS     current
        DESCRIPTION
            "The local Confederation Identification Number.

             This value will be zero (0) if this BGP Speaker is not
             a confederation router."
        REFERENCE
            "RFC 3065 - Autonomous System Confederations for BGP"
        ::= { bgpM2CfgBaseScalarASConfedExts 2 }






_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA05587 for <[e-mail]>; Mon, 17 Mar 2003 13:41:17 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A02E991236; Mon, 17 Mar 2003 13:40:55 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C0AC91237; Mon, 17 Mar 2003 13:40:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5BB1B91236 for <[e-mail]>; Mon, 17 Mar 2003 13:40:54 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 4220F5DE7F; Mon, 17 Mar 2003 13:40:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E36845DE56 for <[e-mail]>; Mon, 17 Mar 2003 13:40:53 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2HIennB098456; Mon, 17 Mar 2003 13:40:49 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2HIeiNp098441; Mon, 17 Mar 2003 13:40:44 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2HIedq29162; Mon, 17 Mar 2003 13:40:39 -0500 (EST)
Date: Mon, 17 Mar 2003 13:40:38 -0500
From: Jeffrey Haas <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: [e-mail], Yakov Rekhter <[e-mail]>
Subject: Re: draft-ietf-idr-bgp4-mib-10.txt to PS
Message-ID: <[e-mail]>
References: <000401c2ecaf$bb46b380$0301a8c0@tom3>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <000401c2ecaf$bb46b380$0301a8c0@tom3>; from [e-mail] on Mon, Mar 17, 2003 at 12:20:47PM -0000
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Tom,

On Mon, Mar 17, 2003 at 12:20:47PM -0000, Tom Petch wrote:
> I think that this draft needs some revision before advancement.

Thanks for the many suggestions.  Others have made similar
suggestions, specifically Bert to fix all of the boilerplate,
off-list.

> IpAddress is frowned upon,

I don't believe we can utilize InetAddress.
Do you have a better suggestion?

> the e-mail is no longer merit.net; etc etc.  And there
> are a raft of SMI issues where this SMI would not be allowed if this
> were a new MIB module but may be here since this is really a converted
> SMIv1 module (issues which keep changing and which I always have to
> research most carefully).

The whole point is to document what *is* deployed without making serious
changes to the MIB - we can't do that.  The v2MIB is intended to let
us get the protocol as deployed properly documnted.

> More debatably, I would prefer the base bgp document to have a
> relatively clean last call before delving too deep into this.

If there are particular points that are reflected in the current v1MIB
that you believe are going to be contentious, please point them out.
I think we're pretty close to being "cooked" on the base draft and 
the portions relevant to the v1MIB are very unlikely to change.

Then again, thats what last call is for!

> We did
> remove MIB information from the base document which means this
> probably now needs more adding to it eg on start event (now more than
> one), error codes and such like.

Right, but much of that was relevant to the v2mib.  Can you point out
specific items in the v1MIB that are of concern?

Thanks for your input.

> Tom Petch
> [e-mail]

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA04508 for <[e-mail]>; Mon, 17 Mar 2003 13:08:16 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 540DC9123D; Mon, 17 Mar 2003 13:07:56 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2E5291236; Mon, 17 Mar 2003 13:07:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5DCE791237 for <[e-mail]>; Mon, 17 Mar 2003 13:07:52 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E32515DE6D; Mon, 17 Mar 2003 13:07:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by segue.merit.edu (Postfix) with ESMTP id B0FC75DD8D for <[e-mail]>; Mon, 17 Mar 2003 13:07:52 -0500 (EST)
Received: from tom3 (1Cust213.tnt9.lnd4.gbr.da.uu.net [62.188.138.213]) by shockwave.systems.pipex.net (Postfix) with SMTP id 75AC21600038D; Mon, 17 Mar 2003 18:07:50 +0000 (GMT)
Message-ID: <000401c2ecaf$bb46b380$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>, "Yakov Rekhter" <[e-mail]>
Subject: Re: draft-ietf-idr-bgp4-mib-10.txt to PS
Date: Mon, 17 Mar 2003 12:20:47 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

I think that this draft needs some revision before advancement.

The SNMP (and other) red tape has moved on.  There is a new boiler
plate for section 5, the SNMP 257x RFC have been superseded by 34xx,
the references need splitting into normative and not, IpAddress is
frowned upon, the e-mail is no longer merit.net; etc etc.  And there
are a raft of SMI issues where this SMI would not be allowed if this
were a new MIB module but may be here since this is really a converted
SMIv1 module (issues which keep changing and which I always have to
research most carefully).

More debatably, I would prefer the base bgp document to have a
relatively clean last call before delving too deep into this.  We did
remove MIB information from the base document which means this
probably now needs more adding to it eg on start event (now more than
one), error codes and such like.
Tom Petch
[e-mail]

-----Original Message-----
From: Yakov Rekhter <[e-mail]>
To: [e-mail] <[e-mail]>
Date: 10 March 2003 16:38
Subject: draft-ietf-idr-bgp4-mib-10.txt to PS


>Folks,
>
>This is to start the WG Last Call on advancing
draft-ietf-idr-bgp4-mib-10.txt
>to a Proposed Standard. The Last Call ends  March 24.
>
>Yakov.



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA25571 for <[e-mail]>; Fri, 14 Mar 2003 17:42:26 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 705AA91205; Fri, 14 Mar 2003 17:41:59 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A6D491213; Fri, 14 Mar 2003 17:41:59 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1BA3E91205 for <[e-mail]>; Fri, 14 Mar 2003 17:41:58 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0A6875DF13; Fri, 14 Mar 2003 17:41:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from hotmail.com (bay1-f76.bay1.hotmail.com [65.54.245.76]) by segue.merit.edu (Postfix) with ESMTP id AF2015DF0C for <[e-mail]>; Fri, 14 Mar 2003 17:41:57 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 14 Mar 2003 14:41:57 -0800
Received: from 65.194.140.2 by by1fd.bay1.hotmail.msn.com with HTTP; Fri, 14 Mar 2003 22:41:57 GMT
X-Originating-IP: [65.194.140.2]
From: "Bruno Rijsman" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Date: Fri, 14 Mar 2003 17:41:57 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 14 Mar 2003 22:41:57.0261 (UTC) FILETIME=[EB31BBD0:01C2EA7A]
Sender: [e-mail]
Precedence: bulk

>In draft-ietf-idr-bgp4-mibv2-03 what is the difference between
>bgpM2RouteReflector and bgpM2CfgRouteReflector (and also between
>bgpM2ClusterId and bgpM2CfgClusterId)?

Just to clarify this question: if we have a read-write
bgpM2CfgRouteReflector why do we also need a read-only
bgpM2RouteReflector?





_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA25425 for <[e-mail]>; Fri, 14 Mar 2003 17:37:33 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CF27491201; Fri, 14 Mar 2003 17:37:09 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98FC891205; Fri, 14 Mar 2003 17:37:09 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6622F91201 for <[e-mail]>; Fri, 14 Mar 2003 17:37:08 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 531195DEC0; Fri, 14 Mar 2003 17:37:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from hotmail.com (bay1-f173.bay1.hotmail.com [65.54.245.173]) by segue.merit.edu (Postfix) with ESMTP id F28CD5DEB2 for <[e-mail]>; Fri, 14 Mar 2003 17:37:07 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 14 Mar 2003 14:37:07 -0800
Received: from 65.194.140.2 by by1fd.bay1.hotmail.msn.com with HTTP; Fri, 14 Mar 2003 22:37:07 GMT
X-Originating-IP: [65.194.140.2]
From: "Bruno Rijsman" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: bgpM2RouteReflector vs bgpM2CfgRouteReflector
Date: Fri, 14 Mar 2003 17:37:07 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 14 Mar 2003 22:37:07.0494 (UTC) FILETIME=[3E7ACC60:01C2EA7A]
Sender: [e-mail]
Precedence: bulk

In draft-ietf-idr-bgp4-mibv2-03 what is the difference between
bgpM2RouteReflector and bgpM2CfgRouteReflector (and also between
bgpM2ClusterId and bgpM2CfgClusterId)?






_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA09267 for <[e-mail]>; Thu, 13 Mar 2003 15:06:07 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id EEA5F91381; Thu, 13 Mar 2003 15:05:43 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9093291384; Thu, 13 Mar 2003 15:05:42 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 46F9491381 for <[e-mail]>; Thu, 13 Mar 2003 15:05:40 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 2AA0C5DFE7; Thu, 13 Mar 2003 15:05:40 -0500 (EST)
Delivered-To: [e-mail]
Received: from hotmail.com (bay1-f60.bay1.hotmail.com [65.54.245.60]) by segue.merit.edu (Postfix) with ESMTP id D62265DDA2 for <[e-mail]>; Thu, 13 Mar 2003 15:05:39 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 13 Mar 2003 12:05:39 -0800
Received: from 65.194.140.2 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 13 Mar 2003 20:05:39 GMT
X-Originating-IP: [65.194.140.2]
From: "Bruno Rijsman" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Some comments on draft-ietf-idr-bgp4-mibv2-03.txt
Date: Thu, 13 Mar 2003 15:05:39 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 13 Mar 2003 20:05:39.0383 (UTC) FILETIME=[EB215C70:01C2E99B]
Sender: [e-mail]
Precedence: bulk

Two observations on using the RFC number as the OID:

(a) What happens if an RFC is obsoleted by a newer RFC?

(b) It seems that this model is not followed consistently
    (e.g. the OIDs for capability negotiation are not based
    on the RFC number)


>From: Jeffrey Haas <[e-mail]>
>To: Bruno Rijsman <[e-mail]>
>CC: [e-mail]
>Subject: Re: Some comments on draft-ietf-idr-bgp4-mibv2-03.txt
>Date: Thu, 13 Mar 2003 14:34:14 -0500
>
>Bruno,
>
>The general idea was that the extension OID would be based on the RFC
>number.
>
>This is, of course, open to reconsideration.  However, this also keeps
>us from sticking things in the bgp mib extensions that aren't at least
>supported by some RFC.
>
>On Thu, Mar 13, 2003 at 02:26:19PM -0500, Bruno Rijsman wrote:
> > (2) A value still needs to be allocated for XXX in
> >
> >     bgpM2PathAttrExtCommTable OBJECT-TYPE
> >         [...]
> >         DESCRIPTION
> >         [...]
> >             XXX JMH - can not assign the OID until an RFC is published."
> >         ::= { bgpM2PathAttrNonCapExts XXX }
> >
> >     PS - In this case it is not quite clear to me why that has to wait
> >     until the RFC is published.
>
>--
>Jeff Haas
>NextHop Technologies


_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA08916 for <[e-mail]>; Thu, 13 Mar 2003 14:36:26 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 10E109137F; Thu, 13 Mar 2003 14:35:52 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D228B91272; Thu, 13 Mar 2003 14:35:51 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A35F49137F for <[e-mail]>; Thu, 13 Mar 2003 14:35:49 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 727D75E162; Thu, 13 Mar 2003 14:35:09 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D7D4C5E151 for <[e-mail]>; Thu, 13 Mar 2003 14:35:08 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2DJYovY086457; Thu, 13 Mar 2003 14:34:50 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2DJYJNp086324; Thu, 13 Mar 2003 14:34:20 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2DJYEf25276; Thu, 13 Mar 2003 14:34:14 -0500 (EST)
Date: Thu, 13 Mar 2003 14:34:14 -0500
From: Jeffrey Haas <[e-mail]>
To: Bruno Rijsman <[e-mail]>
Cc: [e-mail]
Subject: Re: Some comments on draft-ietf-idr-bgp4-mibv2-03.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Mar 13, 2003 at 02:26:19PM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Bruno,

The general idea was that the extension OID would be based on the RFC
number.

This is, of course, open to reconsideration.  However, this also keeps
us from sticking things in the bgp mib extensions that aren't at least
supported by some RFC.

On Thu, Mar 13, 2003 at 02:26:19PM -0500, Bruno Rijsman wrote:
> (2) A value still needs to be allocated for XXX in
> 
>     bgpM2PathAttrExtCommTable OBJECT-TYPE
>         [...]
>         DESCRIPTION
>         [...]
>             XXX JMH - can not assign the OID until an RFC is published."
>         ::= { bgpM2PathAttrNonCapExts XXX }
> 
>     PS - In this case it is not quite clear to me why that has to wait
>     until the RFC is published.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA08816 for <[e-mail]>; Thu, 13 Mar 2003 14:26:41 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D894191279; Thu, 13 Mar 2003 14:26:22 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 981C891272; Thu, 13 Mar 2003 14:26:22 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2241091279 for <[e-mail]>; Thu, 13 Mar 2003 14:26:21 -0500 (EST)
Received: by segue.merit.edu (Postfix) id F0B5C5E11B; Thu, 13 Mar 2003 14:26:20 -0500 (EST)
Delivered-To: [e-mail]
Received: from hotmail.com (bay1-f117.bay1.hotmail.com [65.54.245.117]) by segue.merit.edu (Postfix) with ESMTP id AA2A55E0FA for <[e-mail]>; Thu, 13 Mar 2003 14:26:20 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 13 Mar 2003 11:26:20 -0800
Received: from 65.194.140.2 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 13 Mar 2003 19:26:19 GMT
X-Originating-IP: [65.194.140.2]
From: "Bruno Rijsman" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Some comments on draft-ietf-idr-bgp4-mibv2-03.txt
Date: Thu, 13 Mar 2003 14:26:19 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 13 Mar 2003 19:26:20.0152 (UTC) FILETIME=[6CEB4780:01C2E996]
Sender: [e-mail]
Precedence: bulk

(1) Type TimeTicks should be imported from SNMPv2-SMI

(2) A value still needs to be allocated for XXX in

    bgpM2PathAttrExtCommTable OBJECT-TYPE
        [...]
        DESCRIPTION
        [...]
            XXX JMH - can not assign the OID until an RFC is published."
        ::= { bgpM2PathAttrNonCapExts XXX }

    PS - In this case it is not quite clear to me why that has to wait
    until the RFC is published.






_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA08640 for <[e-mail]>; Thu, 13 Mar 2003 14:08:17 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id EFABD91271; Thu, 13 Mar 2003 14:07:59 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B94BD91272; Thu, 13 Mar 2003 14:07:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 725B291271 for <[e-mail]>; Thu, 13 Mar 2003 14:07:57 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 575535E151; Thu, 13 Mar 2003 14:07:57 -0500 (EST)
Delivered-To: [e-mail]
Received: from hotmail.com (bay1-f163.bay1.hotmail.com [65.54.245.163]) by segue.merit.edu (Postfix) with ESMTP id 0D01D5E0FA for <[e-mail]>; Thu, 13 Mar 2003 14:07:57 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 13 Mar 2003 11:07:56 -0800
Received: from 65.194.140.2 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 13 Mar 2003 19:07:56 GMT
X-Originating-IP: [65.194.140.2]
From: "Bruno Rijsman" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: bgpM2 module identity in draft-ietf-idr-bgp4-mibv2-03.txt?
Date: Thu, 13 Mar 2003 14:07:56 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 13 Mar 2003 19:07:56.0653 (UTC) FILETIME=[DB2EB1D0:01C2E993]
Sender: [e-mail]
Precedence: bulk

Okay, thanks Jeffrey.

Meanwhile, I found one very minor issue in the -03 version of the draft:

BGP4-V2-MIB DEFINITIONS ::= BEGIN
    IMPORTS
        [...]
        -- Note that the following reference to INET-ADDRESS-MIB
        -- refers to the version as published in the RFC 2851
        -- update internet draft.
        InetAddressType, InetAddress, InetPortNumber,
        InetAutonomousSystemNumber, InetAddressPrefixLength
            FROM INET-ADDRESS-MIB

The reference to RFC 2851 should be replaced by a reference to
RFC 3291 because InetPortNumber is only defined in RFC 3291.



>From: Jeffrey Haas <[e-mail]>
>To: Bruno Rijsman <[e-mail]>
>CC: [e-mail]
>Subject: Re: bgpM2 module identity in draft-ietf-idr-bgp4-mibv2-03.txt?
>Date: Thu, 13 Mar 2003 14:02:46 -0500
>
>Bruno,
>
>We will be pursuing getting a MIB-II OID as part of the next version of
>the draft.  I had been waiting on two things to occur:
>o Further discussion on the contents of this MIB
>o The BGP FSM text to become finalized so that it can be properly
>   incorporated into the MIB.
>
>This process will probably be started after the upcoming IETF.
>In the meanwhile, please be on the lookup for a new issue of the MIBv2
>draft.  All comments are appreciated.
>
>
>On Thu, Mar 13, 2003 at 01:25:32PM -0500, Bruno Rijsman wrote:
> > Has a value for XXX already been allocated for the bgpM2 module identity 
>of
> > BGP4-V2-MIB (in draft-ietf-idr-bgp4-mibv2-03.txt)? If not, when is this
> > expected to happen?
> >
> > BGP4-V2-MIB DEFINITIONS ::= BEGIN
> >     [...]
> >     bgpM2 MODULE-IDENTITY
> >         [...]
> >         ::= { mib-2 XXX }    <=== HERE
>
>--
>Jeff Haas
>NextHop Technologies


_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA08627 for <[e-mail]>; Thu, 13 Mar 2003 14:05:35 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D9A839126E; Thu, 13 Mar 2003 14:04:13 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF03491271; Thu, 13 Mar 2003 14:04:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B7ACF9126E for <[e-mail]>; Thu, 13 Mar 2003 14:03:40 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 678E35E180; Thu, 13 Mar 2003 14:02:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D7E035E17F for <[e-mail]>; Thu, 13 Mar 2003 14:02:57 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.12.8/8.11.1) id h2DJ2s3B084600; Thu, 13 Mar 2003 14:02:54 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.nexthop.com (8.12.8/8.12.8) with ESMTP id h2DJ2pNp084593; Thu, 13 Mar 2003 14:02:51 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h2DJ2kD25218; Thu, 13 Mar 2003 14:02:46 -0500 (EST)
Date: Thu, 13 Mar 2003 14:02:46 -0500
From: Jeffrey Haas <[e-mail]>
To: Bruno Rijsman <[e-mail]>
Cc: [e-mail]
Subject: Re: bgpM2 module identity in draft-ietf-idr-bgp4-mibv2-03.txt?
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Mar 13, 2003 at 01:25:32PM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Bruno,

We will be pursuing getting a MIB-II OID as part of the next version of
the draft.  I had been waiting on two things to occur:
o Further discussion on the contents of this MIB
o The BGP FSM text to become finalized so that it can be properly 
  incorporated into the MIB.

This process will probably be started after the upcoming IETF.
In the meanwhile, please be on the lookup for a new issue of the MIBv2
draft.  All comments are appreciated.


On Thu, Mar 13, 2003 at 01:25:32PM -0500, Bruno Rijsman wrote:
> Has a value for XXX already been allocated for the bgpM2 module identity of 
> BGP4-V2-MIB (in draft-ietf-idr-bgp4-mibv2-03.txt)? If not, when is this 
> expected to happen?
> 
> BGP4-V2-MIB DEFINITIONS ::= BEGIN
>     [...]
>     bgpM2 MODULE-IDENTITY
>         [...]
>         ::= { mib-2 XXX }    <=== HERE

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA08123 for <[e-mail]>; Thu, 13 Mar 2003 13:25:55 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CDAB99126B; Thu, 13 Mar 2003 13:25:35 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F69F9126A; Thu, 13 Mar 2003 13:25:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 054059126B for <[e-mail]>; Thu, 13 Mar 2003 13:25:33 -0500 (EST)
Received: by segue.merit.edu (Postfix) id DC91A5DE10; Thu, 13 Mar 2003 13:25:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from hotmail.com (bay1-f19.bay1.hotmail.com [65.54.245.19]) by segue.merit.edu (Postfix) with ESMTP id 8AE655DD9A for <[e-mail]>; Thu, 13 Mar 2003 13:25:33 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 13 Mar 2003 10:25:33 -0800
Received: from 65.194.140.2 by by1fd.bay1.hotmail.msn.com with HTTP; Thu, 13 Mar 2003 18:25:32 GMT
X-Originating-IP: [65.194.140.2]
From: "Bruno Rijsman" <[e-mail]>
To: [e-mail]
Subject: bgpM2 module identity in draft-ietf-idr-bgp4-mibv2-03.txt?
Date: Thu, 13 Mar 2003 13:25:32 -0500
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 13 Mar 2003 18:25:33.0055 (UTC) FILETIME=[EF1470F0:01C2E98D]
Sender: [e-mail]
Precedence: bulk

Has a value for XXX already been allocated for the bgpM2 module identity of 
BGP4-V2-MIB (in draft-ietf-idr-bgp4-mibv2-03.txt)? If not, when is this 
expected to happen?

BGP4-V2-MIB DEFINITIONS ::= BEGIN
    [...]
    bgpM2 MODULE-IDENTITY
        [...]
        ::= { mib-2 XXX }    <=== HERE





_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.  
http://join.msn.com/?page=features/virus



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA08133 for <[e-mail]>; Mon, 10 Mar 2003 11:38:17 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 443B0912B5; Mon, 10 Mar 2003 11:38:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15E6C912B6; Mon, 10 Mar 2003 11:38:00 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C97F6912B5 for <[e-mail]>; Mon, 10 Mar 2003 11:37:58 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B76D25E2D1; Mon, 10 Mar 2003 11:37:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 2DA8F5E2C7 for <[e-mail]>; Mon, 10 Mar 2003 11:37:58 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2AGbvS72648 for <[e-mail]>; Mon, 10 Mar 2003 08:37:57 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: draft-ietf-idr-bgp4-mib-10.txt to PS
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 10 Mar 2003 08:37:57 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

This is to start the WG Last Call on advancing draft-ietf-idr-bgp4-mib-10.txt
to a Proposed Standard. The Last Call ends  March 24.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA07484 for <[e-mail]>; Mon, 10 Mar 2003 10:28:31 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CCAFC912A8; Mon, 10 Mar 2003 10:28:10 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95F29912AB; Mon, 10 Mar 2003 10:28:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57802912A8 for <[e-mail]>; Mon, 10 Mar 2003 10:28:09 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 43DDA5E2B6; Mon, 10 Mar 2003 10:28:09 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id B1AE15E2B4 for <[e-mail]>; Mon, 10 Mar 2003 10:28:08 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h2AFS8S67476; Mon, 10 Mar 2003 07:28:08 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: BGP WG meeting - final agenda
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 10 Mar 2003 07:28:08 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Inter-Domain Routing (IDR)

Wednesday, March 19 1530-1730
=============================

Chairs: Sue Hares ([e-mail]), Yakov Rekhter ([e-mail])

Agenda:

1530-1545 Administrivia
 Yakov Rekhter

            Agenda Bashing
            Minutes
            Blue Sheets
            WG Document Status 

15:45-16:10 Flexible BGP Communities
 Andrew Lange

 http://www.ietf.org/internet-drafts/draft-lange-flexible-bgp-communities-00.txt

16:10-16:25 BGP Security Vulnerabilities Analysis
 Sandy Murphy

  http://www.ietf.org/internet-drafts/draft-murphy-bgp-vuln-02.txt


16:25-16:35 Wrap Up



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15171 for <[e-mail]>; Thu, 6 Mar 2003 10:47:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8CEA29120C; Thu,  6 Mar 2003 10:47:14 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50A109120A; Thu,  6 Mar 2003 10:47:14 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 768F69120C for <[e-mail]>; Thu,  6 Mar 2003 10:46:43 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B77A85E0D2; Thu,  6 Mar 2003 10:46:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 308B15E0D1 for <[e-mail]>; Thu,  6 Mar 2003 10:46:13 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21281; Thu, 6 Mar 2003 10:44:08 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp4-19.txt
Date: Thu, 06 Mar 2003 10:44:08 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

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

	Title		: A Border Gateway Protocol 4 (BGP-4)
	Author(s)	: Y. Rekhter, T. Li, S. Hares
	Filename	: draft-ietf-idr-bgp4-19.txt
	Pages		: 86
	Date		: 2003-3-5
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol.

The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network reacha-
bility information includes information on the list of Autonomous
Systems (ASs) that reachability information traverses.  This informa-
tion is sufficient to construct a graph of AS connectivity from which
routing loops may be pruned and some policy decisions at the AS level
may be enforced.

BGP-4 provides a set of mechanisms for supporting Classless Inter-
Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include
support for advertising a set of destinations as an IP prefix and
eliminating the concept of network 'class' within BGP.  BGP-4 also
introduces mechanisms which allow aggregation of routes, including
aggregation of AS paths.

Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy deci-
sions that can (and can not) be enforced using BGP. BGP can support
only the policies conforming to the destination-based forwarding
paradigm.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-19.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-19.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-19.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-19.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-19.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA12965 for <[e-mail]>; Tue, 4 Mar 2003 11:52:14 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 330D991255; Tue,  4 Mar 2003 11:51:53 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2CA291258; Tue,  4 Mar 2003 11:51:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C03A991255 for <[e-mail]>; Tue,  4 Mar 2003 11:51:51 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A07B85DEBC; Tue,  4 Mar 2003 11:51:51 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 0DCE65DEBA for <[e-mail]>; Tue,  4 Mar 2003 11:51:51 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h24GpnS74619; Tue, 4 Mar 2003 08:51:49 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Susan Hares" <[e-mail]>
Cc: [e-mail]
Subject: Re: Draft-19 - posted privately 
In-Reply-To: Your message of "Tue, 04 Mar 2003 11:43:33 EST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 04 Mar 2003 08:51:49 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Sue,

> idr group:
> 
> Due to my error, draft-19 did not make the ietf posting.
> Draft-19 is posted on my web site at:
> 
> http://ndzh.com/ietf/draft-ietf-idr-bgp4-19.txt
> 
> My apologies for any inconvience this may cause.

Just to add, (a) the draft will be submitted to the IETF secretariat
right after the IETF, and (b) the draft reflects all the comments
on Andrew's list.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA12696 for <[e-mail]>; Tue, 4 Mar 2003 11:44:11 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 44C1C91252; Tue,  4 Mar 2003 11:43:45 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1670D91255; Tue,  4 Mar 2003 11:43:45 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B786D91252 for <[e-mail]>; Tue,  4 Mar 2003 11:43:43 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9C9775DEB7; Tue,  4 Mar 2003 11:43:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.nexthop.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 07CD55DEB6 for <[e-mail]>; Tue,  4 Mar 2003 11:43:43 -0500 (EST)
Received: (from root@localhost) by presque.nexthop.com (8.11.3/8.11.1) id h24Ghfs94535 for [e-mail]; Tue, 4 Mar 2003 11:43:41 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.nexthop.com (8.11.3/8.11.1) with ESMTP id h24GhXv94516 for <[e-mail]>; Tue, 4 Mar 2003 11:43:33 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: Draft-19 - posted privately
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Tue, 4 Mar 2003 11:43:33 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft-19 - posted privately
Thread-Index: AcLibTF6Ua8mgvfvSUqfmnbZfXNoNQ==
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA12696

idr group:

Due to my error, draft-19 did not make the ietf posting.
Draft-19 is posted on my web site at:

http://ndzh.com/ietf/draft-ietf-idr-bgp4-19.txt

My apologies for any inconvience this may cause.

Sue


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA06233 for <[e-mail]>; Mon, 3 Mar 2003 15:49:21 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 64DB191216; Mon,  3 Mar 2003 15:49:05 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 185889128A; Mon,  3 Mar 2003 15:49:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 641B39124D for <[e-mail]>; Mon,  3 Mar 2003 15:48:03 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 43B2D5DDBF; Mon,  3 Mar 2003 15:48:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id A41815DD98 for <[e-mail]>; Mon,  3 Mar 2003 15:48:02 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h23Km1S12179; Mon, 3 Mar 2003 12:48:01 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: IDR WG meeting draft agenda
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 03 Mar 2003 12:48:01 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

Let Sue and myself know asap if you have any corrections, comments or other...

Yakov
-------------------------------------------------------------------

Inter-Domain Routing (IDR)

Wednesday, March 19 1530-1730
=============================

Chairs: Sue Hares ([e-mail]), Yakov Rekhter ([e-mail])

Agenda:

1530-1545 Administrivia
 Yakov Rekhter

            Agenda Bashing
            Minutes
            Blue Sheets
            WG Document Status 

15:45-16:10 Flexible BGP Communities
 Andrew Lange

 http://www.ietf.org/internet-drafts/draft-lange-flexible-bgp-communities-00.txt


16:10-16:20 Wrap Up



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA02885 for <[e-mail]>; Sat, 1 Mar 2003 02:26:38 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id F1F229120C; Sat,  1 Mar 2003 02:26:17 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9A8D91210; Sat,  1 Mar 2003 02:26:16 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A96FD9120C for <[e-mail]>; Sat,  1 Mar 2003 02:26:15 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 840FD5DF14; Sat,  1 Mar 2003 02:26:15 -0500 (EST)
Delivered-To: [e-mail]
Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id 581CD5DECD for <[e-mail]>; Sat,  1 Mar 2003 02:26:15 -0500 (EST)
Received: by nomad.tcb.net (Postfix, from userid 500) id 16C7055F62; Sat,  1 Mar 2003 00:26:10 -0700 (MST)
Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 140DB3E83 for <[e-mail]>; Sat,  1 Mar 2003 00:26:10 -0700 (MST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: [e-mail]
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Regarding BGP Router ID 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 01 Mar 2003 00:26:04 -0700
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> The IBGP peering is between Y & Z.  For the VRFs y is attached to, all the 
> prefixes get advertised to Z with nexthop of Y. Now the point that i am 
> raising is in the OPEN messages to x and Z, y sends Y which turns out to be 
> the next hop for the VPNIPv4 prefixes. Hence i said that there is a potential 
> for security issues in the case of VPNs where we want the prefixes as well
> as the nexthops protected. 

Not sure what your definition of "protected" is, but anyways, there's NO 
reason the BGP Identifier MUST be associated with any NEXT_HOP (i.e., in 
your example above there's no requirement that y set the value of the 
NEXT_HOP to Y when advertising prefixes to x or Z, or even that Y be the 
BGP Identifier for Y).  

The draft Enke cited takes this one step further and allows near arbitrary 
selection of the value, and requires uniqueness only within an AS (or AS 
Confederation).

-danny