Re: [secdir] Security review of draft-ietf-pce-questions-06

["Adrian Farrel" <[e-mail]>]

Hi Ben,

So you don't like my proposed solution?

I am not quite sure what you do consider a resolution to your concern. I can see three options:

1. Add security-related text to each section of this document.
2. Beef up the Security Considerations section with a subsection related to each section of the document.
3. Add a new section "How Secure is my PCE-Enabled System?" as I suggested.

Do you have a preference among these, or is there another option you like better?

Thanks,
Adrian


> -----Original Message-----
> From: Ben Laurie [mailto:[e-mail]]
> Sent: 09 July 2014 15:04
> To: [e-mail]
> Cc: IETF Discussion List; [e-mail]; The IESG
> Subject: Re: Security review of draft-ietf-pce-questions-06
> 
> On 9 July 2014 09:55, Adrian Farrel <[e-mail]> wrote:
> > Hi Ben,
> >
> > Thanks for taking the time to review this document and for posting your
> comments to the IETF discussion list so that we can consider them as last call
> comments.
> >
> > [snip]
> >
> >> The security considerations section makes this claim:
> >>
> >> "This informational document does not define any new protocol elements
> >> or mechanism.  As such, it does not introduce any new security
> >> issues."
> >>
> >> I agree with the premise, but not the conclusion: just because an RFC
> >> does not introduce new security issues, that does not mean that there
> >> are no security considerations.
> >>
> >> Indeed, this RFC discusses many things that have quite serious
> >> security considerations, without mentioning any of them. For example,
> >> section 4 "How Do I Find My PCE?" (the very first question) advocates
> >> a number of potentially completely insecure mechanisms with no mention
> >> of their security properties (or otherwise). This is obviously
> >> pervasive, given the stance taken in the security considerations.
> >>
> >> The document does mention that RFC 6952 gives a security analysis for
> >> PCEP, and perhaps this is sufficient but it seems to me that a
> >> document intended to give useful background information to noobs
> >> should include security directly in that information rather than defer
> >> to another giant document (which mixes PCEP info with other
> >> protocols).
> >
> > I don't believe that this document is strong on "advocacy", but discusses which
> tools are out there and what some people do.
> >
> > Previous PCE RFCs have given some attention to security concerns in the use of
> PCE (RFC 4655), PCE discovery (RFC 4674, RFC 5088. RFC 5089), and the PCEP (RFC
> 4657 and RFC 5440). As such, "PCE Security" was not deemed by the authors to be
> a previously "unanswered question" and so did not need attention in this
> document.
> >
> > That said, you are correct that the various sections do not discuss the security
> implications relating to those sections. I would be pretty loathe to add security
> text to each section in this document: I think that would make the document
> heavy and less likely to be read by its intended consumers (it is not targeting
> "noobs" although they are welcome to read it).
> 
> Your position appears to be that they will then go on to read much
> heavier documents in order to discover the security properties of the
> solutions you suggest, which seems a little unlikely, particularly if
> there's no mention of the necessity to do so.
> 
> Or perhaps you think security is not important?
> 
> > Perhaps a solution to this *is* to treat Security as an unanswered question and
> add a section "How Secure is my PCE-Enabled System?" I can't think of a lot to
> add there except for general egg-sucking guidance, but there would be a pointer
> to the TCP-AO discussions currently going on in the WG. What do you think of
> that as a way forward?
> 
> I have no idea what discussions are going on, but once more, if you
> are concerned about "heaviness" of documentation, pointing at ongoing
> discussions does not strike me as a route to lightness.