Subject: Re: slides from IETF idr meeting Mar 19, 2003

From: [email-masked]
Date: Mon, 31 Mar 2003 11:10:23 -0500 (EST)

>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

Date: Mon, 31 Mar 2003 11:10:23 -0500 (EST)
From: [email-masked]
To: [email-masked], [email-masked], [email-masked]
Subject: Re: slides from IETF idr meeting Mar 19, 2003
Sender: [email-masked]

>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

Date: Mon, 31 Mar 2003 07:59:51 -0800
From: David Meyer <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP protocol analysis
Sender: [email-masked]

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:    [email-masked]
>> To:      IETF-Announce: ;
>> cc:      [email-masked]
>> 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:
>> 	[email-masked].
>> 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="[email-masked]"
>> 
>> Content-Type: text/plain
>> Content-ID:	<[email-masked]>
>> 
>> 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:	<[email-masked]>
>> 
>> - --OtherAccess--
>> 
>> - --NextPart--
>> 
>> 
>> 
>> ------- End of Forwarded Message

To: [email-masked]
Subject: BGP protocol analysis
Date: Mon, 31 Mar 2003 07:27:50 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Please review and comment on the BGP Protocol Analysis draft.

Yakov.
------- Forwarded Message

Date:    Mon, 24 Mar 2003 07:25:25 -0500
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], "Susan Hares" <[email-masked]>, "IDR WG (E-mail)" <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Mon, 31 Mar 2003 10:01:37 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, 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

To: [email-masked]
Cc: "Susan Hares" <[email-masked]>, "IDR WG (E-mail)" <[email-masked]>
Subject: Re: Issue 19) Security Considerations 
Date: Mon, 31 Mar 2003 06:17:04 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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.

To: Jeffrey Haas <[email-masked]>
Cc: Alex Zinin <[email-masked]>, [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Mon, 31 Mar 2003 06:07:32 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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.

To: [email-masked]
Cc: "Susan Hares" <[email-masked]>, "Joris Dobbelsteen" <[email-masked]>, "IDR WG (E-mail)" <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Sat, 29 Mar 2003 17:14:17 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Curtis Villamizar 
writes:
> 
> In message <[email-masked].
> 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:[email-masked]]
> > Sent: Thursday, March 27, 2003 12:52 PM
> > To: Joris Dobbelsteen
> > Cc: IDR WG (E-mail)
> > Subject: Re: Issue 19) Security Considerations 
> > 
> > 
> > 
> > In message <[email-masked]>, "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: [email-masked] [mailto:[email-masked]]On Behalf Of
> > > >Curtis Villamizar
> > > >Sent: Thursday, 27 March 2003 1:45
> > > >To: John Leslie
> > > >Cc: Curtis Villamizar; Alex Zinin; [email-masked]
> > > >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
> > 
> 

To: "Susan Hares" <[email-masked]>
Cc: [email-masked], "Joris Dobbelsteen" <[email-masked]>, "IDR WG (E-mail)" <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Sat, 29 Mar 2003 15:56:16 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]
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:[email-masked]]
> Sent: Thursday, March 27, 2003 12:52 PM
> To: Joris Dobbelsteen
> Cc: IDR WG (E-mail)
> Subject: Re: Issue 19) Security Considerations 
> 
> 
> 
> In message <[email-masked]>, "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: [email-masked] [mailto:[email-masked]]On Behalf Of
> > >Curtis Villamizar
> > >Sent: Thursday, 27 March 2003 1:45
> > >To: John Leslie
> > >Cc: Curtis Villamizar; Alex Zinin; [email-masked]
> > >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
> 

content-class: urn:content-classes:message
Subject: RE: Issue 19) Security Considerations
Date: Fri, 28 Mar 2003 09:29:30 -0500
From: "Susan Hares" <[email-masked]>
To: "Joris Dobbelsteen" <[email-masked]>, "IDR WG (E-mail)" <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
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:[email-masked]]
>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: [email-masked] [mailto:[email-masked]]On Behalf Of
>> >Curtis Villamizar
>> >Sent: Thursday, 27 March 2003 1:45
>> >To: John Leslie
>> >Cc: Curtis Villamizar; Alex Zinin; [email-masked]
>> >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
>> >
>
>
>

content-class: urn:content-classes:message
Subject: RE: Issue 19) Security Considerations 
Date: Fri, 28 Mar 2003 08:42:49 -0500
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>, "Joris Dobbelsteen" <[email-masked]>
Cc: "IDR WG (E-mail)" <[email-masked]>
Sender: [email-masked]

Curtis:

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

Is this correct?

Sue

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

In message <[email-masked]>, "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: [email-masked] [mailto:[email-masked]]On Behalf Of
> >Curtis Villamizar
> >Sent: Thursday, 27 March 2003 1:45
> >To: John Leslie
> >Cc: Curtis Villamizar; Alex Zinin; [email-masked]
> >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

content-class: urn:content-classes:message
Subject: RE: Issue 19) Security Considerations 
Date: Fri, 28 Mar 2003 08:32:27 -0500
From: "Susan Hares" <[email-masked]>
To: "Joris Dobbelsteen" <[email-masked]>, "IDR WG (E-mail)" <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
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: [email-masked] [mailto:[email-masked]]On Behalf Of
>Curtis Villamizar
>Sent: Thursday, 27 March 2003 1:45
>To: John Leslie
>Cc: Curtis Villamizar; Alex Zinin; [email-masked]
>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
>

From: "Joris Dobbelsteen" <[email-masked]>
To: "'IDR WG (E-mail)'" <[email-masked]>
Subject: RE: Issue 19) Security Considerations
Date: Fri, 28 Mar 2003 14:30:05 +0100
Importance: Normal
Sender: [email-masked]

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:[email-masked]]
>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: [email-masked] [mailto:[email-masked]]On Behalf Of
>> >Curtis Villamizar
>> >Sent: Thursday, 27 March 2003 1:45
>> >To: John Leslie
>> >Cc: Curtis Villamizar; Alex Zinin; [email-masked]
>> >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
>> >
>
>
>

To: "Joris Dobbelsteen" <[email-masked]>
Cc: "IDR WG (E-mail)" <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Thu, 27 Mar 2003 12:52:19 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, "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: [email-masked] [mailto:[email-masked]]On Behalf Of
> >Curtis Villamizar
> >Sent: Thursday, 27 March 2003 1:45
> >To: John Leslie
> >Cc: Curtis Villamizar; Alex Zinin; [email-masked]
> >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

From: "Joris Dobbelsteen" <[email-masked]>
To: "IDR WG (E-mail)" <[email-masked]>
Subject: RE: Issue 19) Security Considerations 
Date: Thu, 27 Mar 2003 09:18:45 +0100
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]On Behalf Of
>Curtis Villamizar
>Sent: Thursday, 27 March 2003 1:45
>To: John Leslie
>Cc: Curtis Villamizar; Alex Zinin; [email-masked]
>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
>

To: John Leslie <[email-masked]>
Cc: Curtis Villamizar <[email-masked]>, Alex Zinin <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Wed, 26 Mar 2003 19:45:16 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

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

To: "Joris Dobbelsteen" <[email-masked]>
Cc: "IDR WG (E-mail)" <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Wed, 26 Mar 2003 16:51:30 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, "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

From: "Joris Dobbelsteen" <[email-masked]>
To: "IDR WG (E-mail)" <[email-masked]>
Subject: RE: Issue 19) Security Considerations 
Date: Wed, 26 Mar 2003 14:37:25 +0100
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]On Behalf Of
>Curtis Villamizar
>Sent: Tuesday, 25 March 2003 21:32
>To: Alex Zinin
>Cc: John Leslie; [email-masked]
>Subject: Re: Issue 19) Security Considerations 
>
>
>
>In message <[email-masked]>, 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 <[email-masked]> 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 <[email-masked]>
>> 
>> >> 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 <[email-masked]>
>> 
>> 
>

To: Alex Zinin <[email-masked]>
Cc: John Leslie <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Tue, 25 Mar 2003 15:31:49 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, 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 <[email-masked]> 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 <[email-masked]>
> 
> >> 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 <[email-masked]>
> 
> 

Date: Tue, 25 Mar 2003 08:48:08 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: John Leslie <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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 <[email-masked]> 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 <[email-masked]>

>> 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 <[email-masked]>

Date: Mon, 24 Mar 2003 23:52:25 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: John Leslie <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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 <[email-masked]> wrote:
>> Jeffrey Haas <[email-masked]> wrote:
>>> Alex Zinin <[email-masked]> wrote:
>>> Jeffrey Haas <[email-masked]> 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 <[email-masked]>

Date: Mon, 24 Mar 2003 23:39:31 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Kunihiro Ishiguro <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked], "Steven M.Bellovin" <[email-masked]>
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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

To: Jeffrey Haas <[email-masked]>
Cc: Alex Zinin <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Mon, 24 Mar 2003 22:09:12 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, 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

Date: Mon, 24 Mar 2003 17:29:32 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked], "Steven M.Bellovin" <[email-masked]>
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

>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

Date: Mon, 24 Mar 2003 20:03:47 -0500
From: Jeffrey Haas <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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

Date: Mon, 24 Mar 2003 16:45:04 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: David Meyer <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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

Date: Mon, 24 Mar 2003 16:43:57 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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

Date: Mon, 24 Mar 2003 16:39:27 -0800
From: David Meyer <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

>> > 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

Date: Mon, 24 Mar 2003 19:37:42 -0500
From: Jeffrey Haas <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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

Date: Mon, 24 Mar 2003 16:32:58 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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

Date: Mon, 24 Mar 2003 19:20:16 -0500
From: Jeffrey Haas <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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

Date: Mon, 24 Mar 2003 16:15:41 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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

Date: Mon, 24 Mar 2003 17:36:03 -0500
From: Jeffrey Haas <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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

Date: Mon, 24 Mar 2003 12:05:18 -0800
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked], "Steven M.Bellovin" <[email-masked]>
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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

Date: Mon, 24 Mar 2003 11:23:41 -0500 (EST)
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations
Cc: [email-masked], [email-masked]
Sender: [email-masked]

>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

To: Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Mon, 24 Mar 2003 06:23:42 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp-analysis-00.txt
Date: Mon, 24 Mar 2003 07:25:25 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: Randy Bush <[email-masked]>
Date: Sun, 23 Mar 2003 11:11:54 -0800
To: Curtis Villamizar <[email-masked]>
Cc: IDR WG <[email-masked]>
Subject: Re: Issue 19) Security Considerations 
Sender: [email-masked]

>>> 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

To: Randy Bush <[email-masked]>
Cc: Curtis Villamizar <[email-masked]>, IDR WG <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Sun, 23 Mar 2003 14:10:01 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, 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

From: Randy Bush <[email-masked]>
Date: Sun, 23 Mar 2003 11:03:19 -0800
To: Curtis Villamizar <[email-masked]>
Cc: IDR WG <[email-masked]>
Subject: Re: Issue 19) Security Considerations 
Sender: [email-masked]

> 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

To: "Joris Dobbelsteen" <[email-masked]>
Cc: [email-masked], "IDR WG (E-mail)" <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Sun, 23 Mar 2003 13:56:48 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, "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: [email-masked] On Behalf Of Curtis Villamizar
> >Sent: Sunday, 23 March 2003 6:10
> >Subject: Re: Issue 19) Security Considerations 
> >
> >In message <[email-masked]>, 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
> >
> 

From: "Joris Dobbelsteen" <[email-masked]>
To: <[email-masked]>, "IDR WG (E-mail)" <[email-masked]>
Subject: RE: Issue 19) Security Considerations 
Date: Sun, 23 Mar 2003 19:21:49 +0100
Importance: Normal
Sender: [email-masked]

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: [email-masked] On Behalf Of Curtis Villamizar
>Sent: Sunday, 23 March 2003 6:10
>Subject: Re: Issue 19) Security Considerations 
>
>In message <[email-masked]>, 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
>

To: Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked], Randy Bush <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Sun, 23 Mar 2003 00:09:37 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, 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

Date: Sat, 22 Mar 2003 20:51:05 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

>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

Date: Sat, 22 Mar 2003 20:47:03 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: [email-masked]
Cc: Randy Bush <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations 
Sender: [email-masked]

>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

To: Kunihiro Ishiguro <[email-masked]>
Cc: Randy Bush <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Sat, 22 Mar 2003 23:13:19 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, 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.

To: [email-masked]
Cc: Kunihiro Ishiguro <[email-masked]>, [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Sat, 22 Mar 2003 22:04:07 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, [email-masked]
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

To: Randy Bush <[email-masked]>
Cc: Kunihiro Ishiguro <[email-masked]>, [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Sat, 22 Mar 2003 18:55:42 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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.

From: Randy Bush <[email-masked]>
Date: Sat, 22 Mar 2003 14:50:24 -0800
To: Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Sender: [email-masked]

> 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

Date: Sat, 22 Mar 2003 13:51:19 -0800
From: [email-masked]
To: Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

> >>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

Date: Sat, 22 Mar 2003 16:50:13 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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

Date: Sat, 22 Mar 2003 13:21:19 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations 
Sender: [email-masked]

>>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

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: questions about the index of the bgpM2PeerTable
Date: Sat, 22 Mar 2003 16:13:50 -0500
Sender: [email-masked]

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

Date: Sat, 22 Mar 2003 12:55:52 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: Randy Bush <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations 
Sender: [email-masked]

>> 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

Date: Sat, 22 Mar 2003 12:42:26 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations 
Sender: [email-masked]

>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

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Sat, 22 Mar 2003 11:27:16 -0700
Sender: [email-masked]

> 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

From: Randy Bush <[email-masked]>
Date: Sat, 22 Mar 2003 10:19:42 -0800
To: Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations 
Sender: [email-masked]

> 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

To: Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Sat, 22 Mar 2003 12:37:37 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, 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

Date: Sat, 22 Mar 2003 08:54:23 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Sender: [email-masked]

>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

Date: Sat, 22 Mar 2003 08:40:56 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: [email-masked]
Cc: [email-masked], "Naidu,    Venkata" <[email-masked]>, [email-masked]
Subject: Re: Issue 19) Security Considerations 
Sender: [email-masked]

>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

To: Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked], "Naidu,     Venkata" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Sat, 22 Mar 2003 09:54:06 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, 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

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Thu, 20 Mar 2003 19:13:57 -0700
Sender: [email-masked]

> 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

Date: Fri, 21 Mar 2003 21:17:05 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: [email-masked]
Cc: "Naidu, Venkata" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

>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

Date: Fri, 21 Mar 2003 15:02:37 -0800
From: [email-masked]
To: Kunihiro Ishiguro <[email-masked]>
Cc: "Naidu, Venkata" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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 <[email-masked]>
> To: "Naidu, Venkata" <[email-masked]>
> Cc: "[email-masked]'" <[email-masked]>,
>    [email-masked], [email-masked]
> Subject: Re: Issue 19) Security Considerations 
> In-Reply-To: <[email-masked]>
> 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

Date: Fri, 21 Mar 2003 14:32:34 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: "Naidu, Venkata" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations 
Sender: [email-masked]

>  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

Date: Fri, 21 Mar 2003 14:23:42 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations 
Sender: [email-masked]

>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

From: "Naidu, Venkata" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: Issue 19) Security Considerations 
Date: Fri, 21 Mar 2003 17:06:21 -0500
Sender: [email-masked]

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.

Date: Fri, 21 Mar 2003 14:05:59 -0800
From: [email-masked]
To: Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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 <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: Re: Issue 19) Security Considerations 
> In-Reply-To: <[email-masked]>
> 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

To: Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Fri, 21 Mar 2003 16:38:31 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, 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

Date: Fri, 21 Mar 2003 13:11:29 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations 
Sender: [email-masked]

>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

To: Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Fri, 21 Mar 2003 15:56:24 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, 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

Date: Fri, 21 Mar 2003 12:26:13 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

>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

To: [email-masked]
Cc: Curtis Villamizar <[email-masked]>, [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Fri, 21 Mar 2003 14:16:06 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

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 <[email-masked]>, [email-masked]
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: [email-masked]
> > Delivered-To: [email-masked]
> > Delivered-To: [email-masked]
> > To: [email-masked]
> > Cc: [email-masked], [email-masked], [email-masked],
> >    [email-masked]
> > Reply-To: [email-masked]
> > Subject: Re: Issue 19) Security Considerations 
> > In-reply-to: Your message of "Fri, 21 Mar 2003 11:31:32 EST."
> >              <[email-masked]> 
> > Date: Fri, 21 Mar 2003 11:41:05 -0500
> > From: Curtis Villamizar <[email-masked]>
> > 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 <[email-masked]>, 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
> 

Date: Fri, 21 Mar 2003 11:04:33 -0800
From: [email-masked]
To: Curtis Villamizar <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked],
>    [email-masked]
> Reply-To: [email-masked]
> Subject: Re: Issue 19) Security Considerations 
> In-reply-to: Your message of "Fri, 21 Mar 2003 11:31:32 EST."
>              <[email-masked]> 
> Date: Fri, 21 Mar 2003 11:41:05 -0500
> From: Curtis Villamizar <[email-masked]>
> 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 <[email-masked]>, [email-masked] 
> 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

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Fri, 21 Mar 2003 11:41:05 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, [email-masked] 
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

Date: Fri, 21 Mar 2003 11:31:32 -0500 (EST)
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

>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

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Issue 19) Security Considerations 
Date: Fri, 21 Mar 2003 11:09:18 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, [email-masked] 
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

Date: Fri, 21 Mar 2003 08:19:39 -0500 (EST)
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: Issue 19) Security Considerations
Cc: [email-masked]
Sender: [email-masked]

>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

Date: Thu, 20 Mar 2003 21:17:25 -0800
From: [email-masked]
To: Kunihiro Ishiguro <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 19) Security Considerations
Sender: [email-masked]

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: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Date: Thu, 20 Mar 2003 21:01:40 -0800
> From: Kunihiro Ishiguro <[email-masked]>
> To: [email-masked]
> 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

Date: Thu, 20 Mar 2003 21:01:40 -0800
From: Kunihiro Ishiguro <[email-masked]>
To: [email-masked]
Subject: Issue 19) Security Considerations
Sender: [email-masked]

>      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

Date: Thu, 20 Mar 2003 18:33:54 -0500
From: Jeffrey Haas <[email-masked]>
To: Bruno Rijsman <[email-masked]>
Cc: [email-masked]
Subject: Re: questions about the index of the bgpM2PeerTable
Sender: [email-masked]

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

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Subject: questions about the index of the bgpM2PeerTable
Date: Thu, 20 Mar 2003 10:34:07 -0500
Sender: [email-masked]

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

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: bgpM2CfgConfederationRouter in BGP4-V2-MIB
Date: Mon, 17 Mar 2003 17:53:07 -0500
Sender: [email-masked]

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

Date: Mon, 17 Mar 2003 13:40:38 -0500
From: Jeffrey Haas <[email-masked]>
To: Tom Petch <[email-masked]>
Cc: [email-masked], Yakov Rekhter <[email-masked]>
Subject: Re: draft-ietf-idr-bgp4-mib-10.txt to PS
Sender: [email-masked]

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
> [email-masked]

-- 
Jeff Haas 
NextHop Technologies

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: <[email-masked]>, "Yakov Rekhter" <[email-masked]>
Subject: Re: draft-ietf-idr-bgp4-mib-10.txt to PS
Date: Mon, 17 Mar 2003 12:20:47 -0000
Sender: [email-masked]

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
[email-masked]

-----Original Message-----
From: Yakov Rekhter <[email-masked]>
To: [email-masked] <[email-masked]>
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.

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 14 Mar 2003 17:41:57 -0500
Sender: [email-masked]

>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

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: bgpM2RouteReflector vs bgpM2CfgRouteReflector
Date: Fri, 14 Mar 2003 17:37:07 -0500
Sender: [email-masked]

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

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Some comments on draft-ietf-idr-bgp4-mibv2-03.txt
Date: Thu, 13 Mar 2003 15:05:39 -0500
Sender: [email-masked]

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 <[email-masked]>
>To: Bruno Rijsman <[email-masked]>
>CC: [email-masked]
>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

Date: Thu, 13 Mar 2003 14:34:14 -0500
From: Jeffrey Haas <[email-masked]>
To: Bruno Rijsman <[email-masked]>
Cc: [email-masked]
Subject: Re: Some comments on draft-ietf-idr-bgp4-mibv2-03.txt
Sender: [email-masked]

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

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Some comments on draft-ietf-idr-bgp4-mibv2-03.txt
Date: Thu, 13 Mar 2003 14:26:19 -0500
Sender: [email-masked]

(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

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: bgpM2 module identity in draft-ietf-idr-bgp4-mibv2-03.txt?
Date: Thu, 13 Mar 2003 14:07:56 -0500
Sender: [email-masked]

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 <[email-masked]>
>To: Bruno Rijsman <[email-masked]>
>CC: [email-masked]
>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

Date: Thu, 13 Mar 2003 14:02:46 -0500
From: Jeffrey Haas <[email-masked]>
To: Bruno Rijsman <[email-masked]>
Cc: [email-masked]
Subject: Re: bgpM2 module identity in draft-ietf-idr-bgp4-mibv2-03.txt?
Sender: [email-masked]

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

From: "Bruno Rijsman" <[email-masked]>
To: [email-masked]
Subject: bgpM2 module identity in draft-ietf-idr-bgp4-mibv2-03.txt?
Date: Thu, 13 Mar 2003 13:25:32 -0500
Sender: [email-masked]

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

To: [email-masked]
Subject: draft-ietf-idr-bgp4-mib-10.txt to PS
Date: Mon, 10 Mar 2003 08:37:57 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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.

To: [email-masked], [email-masked]
Subject: BGP WG meeting - final agenda
Date: Mon, 10 Mar 2003 07:28:08 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Inter-Domain Routing (IDR)

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

Chairs: Sue Hares ([email-masked]), Yakov Rekhter ([email-masked])

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-19.txt
Date: Thu, 06 Mar 2003 10:44:08 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: "Susan Hares" <[email-masked]>
Cc: [email-masked]
Subject: Re: Draft-19 - posted privately 
Date: Tue, 04 Mar 2003 08:51:49 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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.

content-class: urn:content-classes:message
Subject: Draft-19 - posted privately
Date: Tue, 4 Mar 2003 11:43:33 -0500
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
Subject: IDR WG meeting draft agenda
Date: Mon, 03 Mar 2003 12:48:01 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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 ([email-masked]), Yakov Rekhter ([email-masked])

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

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Regarding BGP Router ID 
Date: Sat, 01 Mar 2003 00:26:04 -0700
Sender: [email-masked]

> 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