Subject: RE: issue 62

From: "Gray, Eric" <[email-masked]>
Date: Wed, 2 Oct 2002 13:56:27 -0400

In addition to the change Yakov proposes, something 
may need to be done with respect to the following
text as well.
-----------------------------------------------------------------------
In section 2 (Introduction), sixth paragraph

   BGP runs over a reliable transport protocol. This eliminates the
   need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing. Any authentication scheme used by the
   transport protocol (e.g., RFC2385 [10]) may be used in addition to
   BGP's own authentication mechanisms. The error notification mechanism
   used in BGP assumes that the transport protocol supports a "graceful"
   close, i.e., that all outstanding data will be delivered before the
   connection is closed.

Could be changed to 

   BGP runs over a reliable transport protocol. This eliminates the
   need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing. Any authentication scheme used by
   the transport protocol (e.g., RFC2385 [10]) may be used. The error
   notification mechanism used in BGP assumes that the transport 
   protocol supports a "graceful" close, i.e., that all outstanding 
   data will be delivered before the connection is closed.
-----------------------------------------------------------------------
In section 4.1 (Message Header Format), after the figure

     Marker:

         This 16-octet field contains a value that the receiver of the
         message can predict.  If the Type of the message is OPEN, or if
         the OPEN message carries no Authentication Information (as an
         Optional Parameter), then the Marker must be all ones.
         Otherwise, the value of the marker can be predicted by some a
         computation specified as part of the authentication mechanism
         (which is specified as part of the Authentication Information)
         used.  The Marker can be used to detect loss of synchronization
         between a pair of BGP peers, and to authenticate incoming BGP
         messages.

This could be changed to:

     Marker:

         This 16-octet field is included for compatibility; it must be
         set to all ones.
----------------------------------------------------------------------
In section 6.1 (Message Header error handling), second paragraph

   The expected value of the Marker field of the message header is all
   ones if the message type is OPEN.  The expected value of the Marker
   field for all other types of BGP messages determined based on the
   presence of the Authentication Information Optional Parameter in the
   BGP OPEN message and the actual authentication mechanism (if the
   Authentication Information in the BGP OPEN message is present). If
   the Marker field of the message header is not the expected one, then
   a synchronization error has occurred and the Error Subcode is set to
   Connection Not Synchronized.

Which could be replaced by

   The expected value of the Marker field of the message header is all
   ones. If the Marker field of the message header is not as expected,
   then a synchronization error has occurred and the Error Subcode is  
   set to Connection Not Synchronized.
-----------------------------------------------------------------------
Also, the last paragraph in section 6.2 (OPEN message error handling)

   If the OPEN message carries Authentication Information (as an
   Optional Parameter), then the corresponding authentication procedure
   is invoked.  If the authentication procedure (based on Authentication
   Code and Authentication Data) fails, then the Error Subcode is set to
   Authentication Failure.

Could be deleted.
------------------------------------------------------------------------
Finally, we need to deal with bullet 6 in Appendix 4 (which will
probably occur anyway since Appendix 4 needs to be re-written to
reflect that this new RFC differs from RFC 1771 instead of 1105).

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

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Wednesday, October 02, 2002 12:24 PM
> To: [email-masked]
> Subject: issue 62
> 
> Folks,
> 
>   62) Deprecate BGP Authentication Optional Parameter from RFC1771
>   ------------------------------------------------------------------------
> ----
>   Status: No Consensus
>   Change: Potentially
>   Summary: We are at consensus, in that we agree that we should deprecate
>    the BGP Authentication Optional Parameter as described in RFC1771 in
>    favor of the mechanism described in RFC2385.  We do not have new text
> for
>    the draft yet, of if we are going to pull the reference entirely.
> 
> I would suggest to remove the following text from the draft:
> 
>          This document defines the following Optional Parameters:
> 
>          a) Authentication Information (Parameter Type 1):
> 
> 
>             This optional parameter may be used to authenticate a BGP
>             peer. The Parameter Value field contains a 1-octet
>             Authentication Code followed by a variable length
>             Authentication Data.
> 
>                 0 1 2 3 4 5 6 7 8
>                 +-+-+-+-+-+-+-+-+
>                 |  Auth. Code   |
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                 |                                                     |
>                 |              Authentication Data                    |
>                 |                                                     |
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>                Authentication Code:
> 
>                   This 1-octet unsigned integer indicates the
>                   authentication mechanism being used. Whenever an
>                   authentication mechanism is specified for use within
>                   BGP, three things must be included in the
>                   specification:
> 
>                   - the value of the Authentication Code which indicates
>                   use of the mechanism,
>                   - the form and meaning of the Authentication Data, and
>                   - the algorithm for computing values of Marker fields.
> 
>                   Note that a separate authentication mechanism may be
>                   used in establishing the transport level connection.
> 
>                Authentication Data:
> 
>                   Authentication Data is a variable length field that is
>                   interpreted according to the value of the
>                   Authentication Code field.
> 
> If there are objections to this, then I would add the following:
> 
>    This document deprecates the use of the Authentication Information
>    optional parameter.
> 
> Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 02 Oct 2002 12:25:24 -0700

Eric,

> may need to be done with respect to the following

The "reliable transport protocol" used by BGP is TCP. With this in mind
how about the following:

   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. Any
   authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be
   used. 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.

Differences between this document and RFC1771 is in Appendix 1,
not Appendix 4. Appendix 1 will have the text to indicate that
the Authentication Information parameter is eliminated.
   
Yakov.