Subject: Re: Issue 19) Security Considerations

From: Danny McPherson <[email-masked]>
Date: Sat, 22 Mar 2003 11:27:16 -0700

> 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: [email-masked]
Date: Mon, 24 Mar 2003 11:23:41 -0500 (EST)

>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

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Fri, 28 Mar 2003 14:30:05 +0100

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

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 28 Mar 2003 08:32:27 -0500

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 

- Joris

>recommendations and implementation experience is provided in separate
>> we justify denying them access to implementations which don't include
>> TCP-MD5.
>
>to meeting security requirements in a way that interoperates with the
>existing installed base.
>
>Curtis
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 28 Mar 2003 09:29:30 -0500

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

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,

The BGP draft might at:
 Security Considerations

- Joris