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

From: "Michael H. Behringer" <[email-masked]>
Date: Wed, 01 Oct 2003 19:12:36 +0200

Hi Ron!

Sorry for the long silence - I was on vacations and am catching up now. To 
your point: "the SP deactivates draft-behringer": You make it sound like 
flicking a switch, but it is not actually a single event and would be 
noticed. Unless you switch off the mechanism on *all* PEs at *exactly* the 
same moment, there is bound to be a state in which a pair of PEs is 
inconsistent: One has it configured, the other not. That would lead to 
logging messages that would be noticed.

So whilst what you describe sounds easy, I don't think it is. [In that 
light, we probably need to scan the draft again to make sure we've allowed 
for incremental deployment ;-) ]

Michael

At 18:14 21/09/2003, Ron Bonica wrote:
> >
> > 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
> >
> >
>
>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