Subject: RE: draft-ietf-l3vpn-l3vpn-auth-00 and draft-behringer-mpls-vpn-auth-02.txt

From: Ron Bonica <[email-masked]>
Date: Fri, 19 Sep 2003 14:20:53 -0400

Folks,

These two drafts are similar in that the both protect against VPN breaches
caused by misconfiguration of the SP network. They differ in the following
respects:

Draft-ietf-l3vpn-l3vpn-auth assumes that the SP network cannot be trusted to
protect against its own misconfiguration. After all, a well intentioned
misunderstanding on the part of the SP might have caused the SP to
misconfigure the VPN. If such a misunderstanding exists, it might also drive
the SP to misconfigure the authentication mechanism as well.

Since the SP network cannot be trusted to protect against its own
misconfiguration, customer equipment must provide checks and balances. In
order to provide these checks and balances, draft-ietf-l3vpn-l3vpn-auth
passes VPN membership information transparently through the SP network.
Customer devices originate VPN membership information and verify VPN
membership at the remote end. Therefore, additional intelligence is required
on customer equipment.

Draft-behringer-mpls-vpn-auth attempts to achieve the same goal without
changing customer equipment. It does this by associating the authentication
key from the PE-CE routing protocol with VPN membership information. This
association raises three issues:

- Many VPN sites to not use a PE-CE routing protocol

- Customer security policy may require each VPN site to use a different
authentication key on the PE-CE routing protocol. In this case, the SP would
need to configure the mapping of VPN information to authentication keys on
the PE. This mapping, itself, would be subject to misconfiguration by the
SP.

- Customer security policy may require each VPN site to change its PE-CE
authentication key periodically. During the key migration period, the SP
would need to configure the mapping of VPN information to authentication
keys on the PE. This mapping, itself, would be subject to misconfiguration
by the SP.

                                                   Ron
                                                  \individual contributor

===========================================
Ronald P. Bonica       Ph: 703 886 1681
vBNS Engineering       page: 1 888 268 8021
Ashburn, Va.
===========================================
"An eye for an eye only ends up making
the whole world blind."
            -- Gandhi

---

From: "Jim Guichard" <[email-masked]>
Date: Fri, 19 Sep 2003 17:01:41 -0400

Hi Ron,

the intention of draft-behringer-mpls-vpn-auth is not to stop the SP from
misconfiguration but rather prevent VPN route leakage in the event of such a
misconfiguration. The draft allows an end customer to verify that the
appropriate configuration has been established at the PE-router, as
otherwise the authentication will fail locally and no routes will be
installed/exported to other sites.

Jim

> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]On Behalf Of Ron
> >Bonica
> >Sent: Friday, September 19, 2003 2:21 PM
> >To: [email-masked]
> >Subject: RE: draft-ietf-l3vpn-l3vpn-auth-00 and
> >draft-behringer-mpls-vpn-auth-02.txt
> >
> >
> >Folks,
> >

---

From: Ron Bonica <[email-masked]>
Date: Sat, 20 Sep 2003 23:59:48 -0400

Jim,

Draft-behringer prevents VPN compromise when caused by many types of
misconfiguration. In this respect, draft-behringer is superior to
draft-ietf-l3vpn. (Draft-ietf-l3vpn doesn't prevent the VPN from being
compromised; it merely provides a mechanism by which the customer can detect
compromise, after it has occurred.)

Draft-behringer, however, cannot prevent VPN compromise when caused by some
types of misconfiguration. Specifically, when the SP misconfigures the VPN
authentication mechanism itself, draft-behringer cannot prevent VPN
compromise. In this case, the customer has a false sense of security, which
is worse than no protection at all.

There are several ways in which the SP might misconfigure the authentication
mechanism. The most obvious is to forget to enable it. Less obvious
opportunities for misconfiguration arise under the following conditions:

- the customer uses a unique key to authenticate the routing protocol on
each PE-CE interface
- the customer changes authentication keys on PE-CE routing protocols
periodically, but does not want to change all keys in one night
- the customer participates in extranets

                                             Ron

> From: Jim Guichard [mailto:[email-masked]]
> Sent: Friday, September 19, 2003 5:02 PM
> To: Ron Bonica; [email-masked]
> > >                                                  \individual
> contributor

---

From: "Jim Guichard" <[email-masked]>
Date: Sun, 21 Sep 2003 08:13:47 -0400

Hi Ron,

> >From: Ron Bonica [mailto:[email-masked]]
> >Sent: Sunday, September 21, 2003 12:00 AM
> >To: Jim Guichard; [email-masked]

If the SP misconfigures the authentication mechanism then the PE-router will
reject routing updates from the CE-router as the MD5 key will not match and
therefore local authentication will fail. Likewise, if a remote PE-router is
misconfigured then a PE-router that receives an update from this router will
fail authentication because of the key mismatch.

Jim

---

From: Ron Bonica <[email-masked]>
Date: Sun, 21 Sep 2003 12:14:50 -0400

> fail authentication because of the key mismatch.

Hi Jim,

Is this always the case? Consider the following scenario:

Draft-behringer has been working nicely in a network for months. While
working another issue, the SP deactivates draft-behringer, network-wide. The
SP is unaware of this misconfiguration and the network runs unprotected for
weeks. The customer is also unaware that the network is running unprotected.
During this period, more misconfigurations follow.

This is the worst example of authentication mechanism misconfiguration that
I can think of. There are more subtle misconfigurations that can come into
play when the customer uses a different authentication key on each PE-CE
interface.

                                   Ron

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Sun, 21 Sep 2003 13:41:00 -0700

>is worse than no protection at all.

That is a strong assertion, one that I have made in the past in other 
security contexts. I now believe that it is wrong in any protocol 
that, when properly implemented, gives actual security. 
Draft-behringer gives some real security, and determining if it is 
implemented is easy for many of the cases.

There are almost no security protocols that cannot be misconfigured. 
The "false sense of security" argument cannot be held against them.

--Paul Hoffman, Director
--VPN Consortium