[secdir] Security review of draft-ietf-grow-ops-reqs-for-bgp-error-handling-05

["Hilarie Orman" <[e-mail]>]

Secdir review of 
Operational Requirements for Enhanced Error Handling Behaviour in BGP-4
draft-ietf-grow-ops-reqs-for-bgp-error-handling-05

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors. Document editors and
WG chairs should treat these comments just like any other last call
comments.

The document intends to specify "requirements for ongoing work" in
handling errors in BGP-4 protocol messages.  The document says that
it will not define the protocol mechanisms for implementing solutions.

A lot of experience and thought has gone into writing this document.
Nonetheless, I had a great deal of trouble finding the requirements
because the writing is narrative and overly wordy.  I would like to
see the requirements stated clearly and separated from the
rationalization.

There are many requirements that seem to be dictated (not to be the
subject of "ongoing work", apparently) and others that are quite vague:

   There is a requirement that where subsets of the
   RIB on a device are no longer reachable from a BGP speaker, or indeed
   an AS, that some visibility of this situation, alongside a mechanism
   to determine the cause is available to an operator.  Whilst, to some
   extent, this can be solved by mandating a sub-requirement of each of
   the aforementioned requirements that a BGP speaker must log where
   such errors occur, and are hence handled, this does not solve all
   cases.

It's difficult to untangle this sort of thing into analyzable requirements.

>From a security standpoint, the requirement that offending BGP
messages be returned to the sender is problematic.  BGP has a
lightweight cryptographic mechanism for protecting message integrity
and providing authentication.  The returned erroneous messages might
help an attacker undermine the protection and thus insert bogus
messages into a channel.  The security considerations should point
out that any new form of error handling requires cryptanalysis.

Some minor editorial comments:

"Whilst" is rarely used in American English.  The synonym "while" is
preferred, but in this document the word "although" would be a better
replacement.  In many cases omission altogether would improve the
sentence.

In this introductory paragraph
   "... numerous incidents have been recorded due to the
   manner in which [RFC4271] specifies errors in routing information
   should be handled."
we do not learn why the "incidents" require any changes to error
handling.  The very term "incident" appears to be a pejorative in the
mind of the author.

Grammo:
	 "It should, however, be noted"
replace with
	 "It should be noted, however"
	 or
	 "Note that ..."