Subject: about :draft-chunzhe-idr-protection-md5-00.txt

From: lidefeng <[email-masked]>
Date: Mon, 02 Sep 2002 15:45:38 +0800

hi,

Thanks for your opinion,however, I have interpretation as follows:

1. The BGP protection method provided by RFC 2385(called RFC 2385 method
later) should maintain one listen socket
for every TCP connection,so if there are many BGP neighbors,RFC 2385 method
should maintain
many listen sockets for these neighbors,while in this situation, the method
provided by draft-chunzhe-idr-protection-md5-00.txt
(called chunzhe method later) need maintain only one listen socket for all
the neighbors.

2. RFC 2385 method provided a protection for Transport Layer, while chunzhe
method provide
a protection for the security of Application Layer,they serve different
function, it can work harmoniously with RFC 2385 to provide
security for both Transport Layer and Application Layer. Then the protection
will be robust.

3. RFC 2385 method have no option for Authentication Algorithm,so we can't
select the authentication method,
while chunzhe method provide the authentication algorithm field,the
authentication algorithm
is not mandatory as MD5.

4. In situation where BGP needs authentication,while LDP(which use TCP as
transport layer protocol) don't support authentication,
RFC 2385 method will be difficult,while chunzhe method can serve it.

Best Regards

Li Defeng

----- Original Message -----
From: "Pedro Roque Marques" <[email-masked]>
To: "lidefeng" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 27, 2002 1:42 AM
Subject: A draft about BGP protection,Please review

> lidefeng  writes:
>
> > 3.0 Security Considerations
>
> >     This BGP extension mechanism provides an simple but efficient
> > method to protect the security of BGP route information,compared
> > with other methods which encrypt the whole BGP message,the impact to
> > the performance of route protocol will be sustainable,and in
> > contrast to the existing BGP security mechanism such as RFC2385,
> > which is from the perspective of the transport layer ,this mechanism
> > takes measure on the application layer and do nothing to the
> > transport layer.
>
> Li,
> RFC 2385 protects you against attacks on the TCP session in addition
> to autenticating the BGP data. Causing a valid BGP session to be reset
> via attacks at the TCP layer is a very effective DOS attack which is
> still possible under your proposal.
>
> Effectivly BGP relies on its transport layer to provide it w/ a
> session. Authentication needs to be a property of that session, since
> events on the session are so or more important than the data in the
> session itself.
>
> Protecting BGP data does not address some of the most important
> concerns.
>
>   Pedro.

---

From: lidefeng <[email-masked]>
Date: Mon, 02 Sep 2002 15:46:27 +0800

hi,

Thanks for your opinion,however, I have interpretation as follows

Best Regards

Li Defeng
----- Original Message -----
From: "John G. Scudder" <[email-masked]>
To: "lidefeng" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, August 27, 2002 1:47 AM
Subject: Re: A draft about BGP protection,Please review

> Since draft-huawei-bgp-protection-md5-00.txt does not protect the
> transport layer, some other form of transport layer protection would
> be required in order to protect against RST attacks and the like.  In
> fact, this is exactly why RFC 2385 style protection was developed as
> a TCP option instead of using the BGP authentication field.
>
> Considering that (a) transport layer protection is required anyway,
> (b) as a subset of its functionality it provides substantially the
> same benefits as application layer protection and (c) it's
> well-deployed already, I don't see the motivation for developing
> application layer protection as your draft describes.
>
> Regards,
>
> --John Scudder
>
> At 2:28 PM +0800 8/26/02, lidefeng wrote:
> >hi,
> >
> >     As to the protection of BGP route information, we propose an
> >efficient mechanism as described
> >in draft-huawei-bgp-protection-md5-00.txt.
> >    Please reviev it as soon as possible.Thanks
> >
> >Regards
> >
> >Li Defeng
> >
> >
> >Attachment converted: JGS TiBook:draft-huawei-bgp-protection-md5
> >(TEXT/R*ch) (000A84F0)
>

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 3 Sep 2002 09:54:51 -0700 (PDT)

lidefeng  writes:

> hi, Thanks for your opinion,however, I have interpretation as
> follows:

> 1. The BGP protection method provided by RFC 2385(called RFC 2385
> method later) should maintain one listen socket for every TCP
> connection,

That is not correct.
TCP MD5 only needs one listen socket for the application. That socket
however needs to have an access control list including the passwds of
the neighbors that are allowed to connect.

> 2. RFC 2385 method provided a protection for Transport Layer, while
> chunzhe method provide a protection for the security of Application
> Layer,they serve different function, it can work harmoniously with
> RFC 2385 to provide security for both Transport Layer and
> Application Layer. Then the protection will be robust.

A model, the OSI model for instance, may be helpful when it help us
understand a given problem. I believe that when we begin talking about
security at the 'application' layer vs 'transport layer' the model is
just obfuscating the issue. Let us put the OSI-speak asside for a
while...

There are two things that need to be authenticated... the BGP protocol
data and the session state. The aproach that you are proposing
autenticates the BGP data only, while the existing aproach does
authenticate both.

The aproaches are not complementary... the aproach you are proposing
is redundant if 2385 is in use. It can not replace 2385 since it does
not provide authentication for session state transitions (i.e. TCP
resets/closes).

> 4. In situation where BGP needs authentication,while LDP(which use
> TCP as transport layer protocol) don't support authentication, RFC
> 2385 method will be difficult,while chunzhe method can serve it.

You can use TCP MD5 over both BGP and LDP... LDP does not have any
authentication fields because it is assumed that it will use a lower
layer mechanism that authenticates TCP state transitions, for instance
TCP MD5.

  Pedro.