Hi Eric, Ben has clarified... > I prefer 1 [Add security-related text to each section of this document], that > way the security advice is likely to be read by whoever reads that section - > that is, by the people who are likely to benefit from it. I've agreed to look at this, but i find myself a tiny bit busy. There is a meeting I have to go to at the end of the week and I have to prepare some material. Will get to this in due course. A > -----Original Message----- > From: Eric Gray [mailto:eric.gray@xxxxxxxxxxxx] > Sent: 17 July 2014 02:15 > To: adrian@xxxxxxxxxxxx; 'Ben Laurie'; 'IETF Discussion List'; secdir@xxxxxxxx > Cc: iesg@xxxxxxxx > Subject: RE: Security review of draft-ietf-pce-questions-06 > > Adrian, > > I think it might be useful to have a little more information in the Security > Considerations section. > > For the example Ben gives, for example, the draft could include text in > the SC section that makes the point Ben made and refers to the RFCs (or other > places) where these issues have been discussed or addressed. > > I am not sure the suggestion was to put security text in each section so > much as to put pointers to relevant places where (admittedly not new) security > issues have already been hashed out. > > I don't think this would be the first draft that had an SC section listing > the issues (old or new) that apply to other sections in the same draft. > > -- > Eric > > -----Original Message----- > From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Adrian Farrel > Sent: Wednesday, July 09, 2014 4:55 AM > To: 'Ben Laurie'; 'IETF Discussion List'; secdir@xxxxxxxx > Cc: iesg@xxxxxxxx > Subject: RE: Security review of draft-ietf-pce-questions-06 > > 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). > > 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? > > Thanks, > Adrian > >