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(_dot_)gray(_at_)ericsson(_dot_)com]
Sent: 17 July 2014 02:15
To: adrian(_at_)olddog(_dot_)co(_dot_)uk; 'Ben Laurie'; 'IETF Discussion
List'; secdir(_at_)ietf(_dot_)org
Cc: iesg(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org] On Behalf Of Adrian
Farrel
Sent: Wednesday, July 09, 2014 4:55 AM
To: 'Ben Laurie'; 'IETF Discussion List'; secdir(_at_)ietf(_dot_)org
Cc: iesg(_at_)ietf(_dot_)org
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