Subject: RE: Authentication in draft-ietf-idr-bgp4-18.txt

From: "Gray, Eric" <[email-masked]>
Date: Wed, 20 Nov 2002 16:42:56 -0500

Alex,

	I think mandating TCP MD5 is a good thing, but 
I am somewhat surprised at the logic of this assertion.  
Given that the BGP specification's previously proposed 
authentication (the one being removed) must not have 
been exactly mandatory (given that nobody seems to have
implemented it), I am not sure that the need to mandate
TCP MD5 follows from the removal of BGP authentication.

	I believe what you are specifically suggesting is
that the specification should explicitly state that TCP
MD5 authentication must be supported by implementation 
(IAW RFC 1264).

	I suggest changing the following (Appendix E, 3rd
paragraph):

   A local system may protect its BGP connections by using the TCP MD5
   Signature Option [RFC2385].

to read:

   A local system may need top protect its BGP connections by using 
   the TCP MD5 Signature Option [RFC2385].  For this reason, a BGP
   implementation MUST support this option.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> Sent: Wednesday, November 20, 2002 3:52 PM
> To: [email-masked]
> Subject: Authentication in draft-ietf-idr-bgp4-18.txt
> 
> Folks,
> 
>  Now that the BGP-internal authentication has been removed
>  from the spec due to lack of implementations, we're left
>  with no mandatory authentication mechanism (required by
>  RFC1264).
> 
>  It's up to the WG to decide what should be done, but seems
>  that saying that implementations MUST implement TCP MD5 would
>  be a good solution.
> 
> --
> Alex

---

From: "Gray, Eric" <[email-masked]>
Date: Thu, 21 Nov 2002 11:14:03 -0500

What RFC actually states as a requirement - as far as I can
tell - is the following:

"The security architecture must include mechanisms for
 authenticating routing messages and may include other 
 forms of protection."

This statement occurs twice (page 2 and page 4) and there is
additional statements to the effect that a statement must be
provided to the IESG - via the Routing AD(s) - as to the 
authentication mechanisms used by the protocol.

While it is almost certain that the intention was that some
mechanism MUST be supported in implementations of a routing
protocol, there is ample opportunity for misunderstanding.
Stating that the "security architecture" must have some form
of authentication is not the same thing as saying that an
implementation must implement this mechanism.  Indeed, given
that the BGP authentication mechanism that seemd previously
to fulfill the RFC 1264 requirement was not implemented, it
seems reasonably clear that most people did not view it as 
an implementation requirement.

However, such a mechanism is needed.  Removing the text that
described BGP authentication removed some degree of ambiguity
since most (if not all) implementations did not implement it.
Many (if not most) actually implemented the TCP MD5 signature
option.

Suddenly declaring existing implementations as non-compliant
is not an issue.  This is a respin of the previous RFC and an
interoperability mode is obvious.  In fact, given that very
many implementations already support TCP MD5 signature option,
it seems likely that use of this interoperability mode has 
already been demonstrated between implementations that do and
do not support this option.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Wednesday, November 20, 2002 7:35 PM
> To: Justin Fletcher
> Cc: Alex Zinin; [email-masked]
> Subject: Re: Authentication in draft-ietf-idr-bgp4-18.txt
> 
> Justin,
> 
> > On Wed, 20 Nov 2002, Alex Zinin wrote:
> >
> > > Folks,
> > >
> > I strongly disagree.
> > This would indicate a change in the base specification; any vendor
> > implementation which had been previously compliant would suddenly be
> > non-compliant if TCP MD5 authentication is not supported.
> >
> > In addition, RFC1264 is an informational; I don't believe conformance
> > should be considered as a requirement for a standards-track document.
> >
> > We could recommend implementation of TCP MD5 for authentication,
> > but it certainly shouldn't be mandatory.
> 
> As Alex mentioned in his e-mail RFC1264 *requires* a mandatory
> authentication mechanism. That is, to have a Draft Standard spec
> that doesn't have a mandatory authentication mechanism is *not* an
> option.
> 
> The BGP-internal authentication has been removed because it wasn't
> implemented. So, the only possible mechanism known to me that could
> be used to satisfy the rfc1264 requirement is TCP MD5 (as it provides
> authentication, and has deployed multi-vendor interoperable
> implementations).
> 
> If you are aware of any other possible mechanism that satisfies
> the rfc1264 requirement *and* has deployed multi-vendor interoperable
> implementatations, please mention it, so that we could consider
> it as an alternative to TCP MD5. In the absence of such an
> alternative we have no choice, but to make TCP MD5 mandatory.
> 
> Yakov.