Subject: RE: Issue 19) Security Considerations

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 21 Mar 2003 17:06:21 -0500

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.

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Fri, 21 Mar 2003 14:32:34 -0800

>  requirements in very near future.

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

---

From: [email-masked]
Date: Fri, 21 Mar 2003 15:02:37 -0800

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

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Fri, 21 Mar 2003 21:17:05 -0800

>specified.  MD5 is the winner by default.  It is widely deployed and

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

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 22 Mar 2003 09:54:06 -0500

> implementation.  We should be technical at here.

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

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Sat, 22 Mar 2003 08:40:56 -0800

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

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 22 Mar 2003 16:50:13 -0500

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

> security consideration section.  I want to hear technical opinin at

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

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Sat, 22 Mar 2003 20:51:05 -0800

>What is the exact requirements that we need out of our security considerations

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

---

From: Alex Zinin <[email-masked]>
Date: Mon, 24 Mar 2003 12:05:18 -0800

Jeff-

[...]

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

> conflicts with the simple TCP statement above.

Sorry, could you explain what conflict you see?

> What is the exact requirements that we need out of our security considerations

[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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 Mar 2003 17:36:03 -0500

Alex,

On Mon, Mar 24, 2003 at 12:05:18PM -0800, Alex Zinin wrote:
> If such commands and API
> 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.

> Sorry, could you explain what conflict you see?

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

> case), as well as a mandatory to implement authentication mechanism.

This was the piece I needed to see.  Thanks.

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Mon, 24 Mar 2003 16:15:41 -0800

Jeff-

> Note however that IPSec is pretty pervasive at the workstation level

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.

> 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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 Mar 2003 19:20:16 -0500

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

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

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Mon, 24 Mar 2003 16:32:58 -0800

Jeff-

> deal with on subjects like this.  Were this not the case, I would

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

> 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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 Mar 2003 19:37:42 -0500

> seems to mean the latter.

This seems clear to me:

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

-- 
Jeff Haas 
NextHop Technologies

---

From: David Meyer <[email-masked]>
Date: Mon, 24 Mar 2003 16:39:27 -0800

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

---

From: Alex Zinin <[email-masked]>
Date: Mon, 24 Mar 2003 16:43:57 -0800

Jeff-

> 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

---

From: Alex Zinin <[email-masked]>
Date: Mon, 24 Mar 2003 16:45:04 -0800

David,

 Stop reading my mind! :)

-- 
Alex

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 Mar 2003 20:03:47 -0500

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

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

-- 
Jeff Haas 
NextHop Technologies

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Mon, 24 Mar 2003 17:29:32 -0800

>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

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 Mar 2003 22:09:12 -0500

> to it that way throughout the document.

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

Curtis

---

From: Alex Zinin <[email-masked]>
Date: Mon, 24 Mar 2003 23:39:31 -0800

Ishi-

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

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

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

---

From: Alex Zinin <[email-masked]>
Date: Mon, 24 Mar 2003 23:52:25 -0800

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

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

---

From: Alex Zinin <[email-masked]>
Date: Tue, 25 Mar 2003 08:48:08 -0800

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

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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 25 Mar 2003 15:31:49 -0500

>   definition of "reliability" and explain how the MD5 option

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

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Wed, 26 Mar 2003 14:37:25 +0100

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]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 26 Mar 2003 16:51:30 -0500

In message <[email-masked]>, "Joris Dobbelsteen" 
> Aren't there more methods for security beside

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: Yakov Rekhter <[email-masked]>
Date: Mon, 31 Mar 2003 06:07:32 -0800

Jeff,

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

Done.

Yakov.