Subject: RE: revised Security Consideration section

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

Yeah, John, as indicated in crossed-mail, I am suggesting
either a complete cut-and-paste or a non-normative reference.
Sandy's draft seems only just now to have become a WG draft
(the reference given by Yakov does not yet exist).  I see
no reason why the BGP draft needs to be held up pending
WG, IESG and IETF processing of Sandy's informational WIP,
however valuable this WIP is.

Obviously, it would be easier to make it a non-normative 
reference.

An analysis of protocol vulnerability is inherently an
open-ended task.  I believe the key reason for rev'ing 
the BGP specification was to update it according to what
implementations really do and to push it forward to
Draft Standard status - not solve the world's problems.  :-)

BGP exists and is massively deployed. Clearly understanding
BGP security risks is important, and this information is
increasingly useful as it is made available.  But let's not
block other important work in the process...

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

> -----Original Message-----
> From: John G. Scudder [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 1:09 PM
> To: Gray, Eric
> Cc: 'Yakov Rekhter'; [email-masked]
> Subject: RE: revised Security Consideration section
> 
> Eric,
> 
> At 11:42 AM -0500 11/21/02, Gray, Eric wrote:
> >	This change is okay with me only if the reference to
> >XXX is non normative.  Otherwise, I would suggest literally
> >including those aspects of Sandy's draft that you think
> >apply to BGP as part of the BGP RFC-to-be.
> 
> The title of Sandy's draft is "BGP Security Vulnerabilities
> Analysis", and the Security Considerations sections says in part:
> 
>    This entire memo is about security, describing an analysis of the
>    vulnerabilities that exist in the BGP protocol.
> 
> Clearly the entire thing applies to BGP.  Are you suggesting a
> complete cut-n-paste of the draft into the main spec?  If not, what
> are you suggesting?
> 
> FWIW, the proposal as written is OK by me.
> 
> Regards,
> 
> --John

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 21 Nov 2002 11:26:03 -0800

Eric,

> block other important work in the process...

Perhaps Alex could comment on whether the IESG would insist
on making Sandy's draft a normative reference, or whether
it would be ok with the IESG to make it non-normative.

Yakov.

---

From: Alex Zinin <[email-masked]>
Date: Thu, 21 Nov 2002 14:31:30 -0500

Eric,

  Some thoughts on this:

  1. The BGP spec will need a security analysis as well
     as the authentication mechanism in order to go through
     the IESG.

  2. Security analysis needs to be specified either in
     the spec itself or in a separate document. If in a
     separate document, both docs will need to go to
     the IESG at the same time (otherwise there is no
     way to ensure that the requirement for a useful
     Security Considerations section is ever satisfied).

  3. Sandy's doc seems to have a quite thorough BGP security
     analysis. If the WG believes that more work needs
     to be done on it, then it does not matter whether
     the text is cut-n-pasted or stays in a separate doc.
     If the WG believes that the security text is good
     enough, then again it doesn't matter and we go back
     to point 2 above.

  Thanks.

-- 
Alex

---

From: Alex Zinin <[email-masked]>
Date: Thu, 21 Nov 2002 14:37:42 -0500

Yakov,

> it would be ok with the IESG to make it non-normative.

I'll check with the IESG. My personal opinion is that
informational is fine here. However, I don't think this
changes much, as the real IESG requirement is for both
docs to be progressed together... Logically they both
will be considered as a single doc anyways, i.e., if
there are any problems with the security doc, the spec
itself will need to wait until those are fixed.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Thu, 21 Nov 2002 14:43:39 -0500

In fact, I just realized that since the sec doc will
be published as INFO (it does not specify any proto
changes), the spec cannot refer to it normatively,
as this would prevent it from going to the STD track.
So, it has to be informative.

-- 
Alex