Subject: Re: Issue 19) Security Considerations

From: Danny McPherson <[email-masked]>
Date: Thu, 20 Mar 2003 19:13:57 -0700

> 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

---

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

>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

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 22 Mar 2003 12:37:37 -0500

> You may believe it or not, there are many BGP speakers which does not

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

> deployment TCP MD5 very minor extension.

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

---

From: Randy Bush <[email-masked]>
Date: Sat, 22 Mar 2003 10:19:42 -0800

> You may believe it or not, there are many BGP speakers which does not

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

randy

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Sat, 22 Mar 2003 12:42:26 -0800

>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

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Sat, 22 Mar 2003 12:55:52 -0800

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

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

---

From: Kunihiro Ishiguro <[email-masked]>
Date: Sat, 22 Mar 2003 13:21:19 -0800

>If the the box has IPsec, there should not be need of less secure TCP

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: [email-masked]
Date: Sat, 22 Mar 2003 13:51:19 -0800

> 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

---

From: Randy Bush <[email-masked]>
Date: Sat, 22 Mar 2003 14:50:24 -0800

> If the the box has IPsec, there should not be need of less secure TCP

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

---

From: Yakov Rekhter <[email-masked]>
Date: Sat, 22 Mar 2003 18:55:42 -0800

Randy,

> md5 is rekeying.  and rekeying is not our big problem, it's any

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: Curtis Villamizar <[email-masked]>
Date: Sat, 22 Mar 2003 22:04:07 -0500

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

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

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 22 Mar 2003 23:13:19 -0500

> only MUST item in BGP sepecification is wrong message for routing

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.

---

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

>IPSEC decryptions are more difficult computations IPSEC actaully makes

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

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 23 Mar 2003 00:09:37 -0500

> consensus for it, I can live with it.

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

> specification and it's deployment.

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]>
Date: Sun, 23 Mar 2003 19:21:49 +0100

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 
>

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 23 Mar 2003 13:56:48 -0500

In message <[email-masked]>, "Joris Dobbelsteen" 
> promote interoperability between other BGP implementations.

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

---

From: Randy Bush <[email-masked]>
Date: Sun, 23 Mar 2003 11:03:19 -0800

> 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

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 23 Mar 2003 14:10:01 -0500

> would such relaxation be well-advised?

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:11:54 -0800

> No.

then i suggest we not waste more time discussing it

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 24 Mar 2003 06:23:42 -0800

Kunihiro,

> also other TCP based protocols such as LDP, I'm ok with it.

LDP supports TCP MD5 today.

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