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

Eric Gray <> Thu, 17 July 2014 01:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DE7941A03C8; Wed, 16 Jul 2014 18:14:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i5p7E1zCThT5; Wed, 16 Jul 2014 18:14:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD15A1A03C7; Wed, 16 Jul 2014 18:14:36 -0700 (PDT)
X-AuditID: c618062d-f79206d0000014d2-31-53c6d0da8983
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E1.C8.05330.AD0D6C35; Wed, 16 Jul 2014 21:22:02 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Wed, 16 Jul 2014 21:14:35 -0400
From: Eric Gray <>
To: "" <>, 'Ben Laurie' <>, 'IETF Discussion List' <>, "" <>
Thread-Topic: Security review of draft-ietf-pce-questions-06
Thread-Index: AQHPl4DqkyRlMMPM/0m6wotMzCFTMpuXuweAgAvMroA=
Date: Thu, 17 Jul 2014 01:14:34 +0000
Message-ID: <>
References: <> <068f01cf9b53$7fc60b30$7f522190$>
In-Reply-To: <068f01cf9b53$7fc60b30$7f522190$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXSPt+6tC8eCDdoXSVv86LnBbLHh8zU2 ixl/JjJbPNs4n8Xiw8KHLA6sHgs2lXosWfKTyWPF5pWMAcxRXDYpqTmZZalF+nYJXBnbH6xh LPinWvHqmloDY4NqFyMnh4SAicS/ZUfYIGwxiQv31gPZXBxCAkcZJSZcPssM4SxnlDj/cgsL SBWbgIbEsTtrGUESIgILGCVeX93IDpJgFlCWuHnkFTOILSxgLfHx4X2gOAdQkY3EtD91IGER ASuJ2U+Og21jEVCV+Lx9BxOIzSvgK9H7+R0rxLJGRomdWzeAzeQEmnP960wwmxHovO+n1jBB 7BKXuPVkPhPE2QISS/acZ4awRSVePv7HCmErSUxaeo4V5AZmAU2J9bv0IVoVJaZ0P2SH2Cso cXLmE5YJjGKzkEydhdAxC0nHLCQdCxhZVjFylBanluWmGxlsYgRG0jEJNt0djHteWh5iFOBg VOLhVfA9FizEmlhWXJl7iFGag0VJnHdW7bxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwe XFbp+kVLixqXfFjsN//c0Zf1ibdF3TWdPWtfP5zyY+/k5y+Crki2Ha9XYpo1u3uHl48zj6lx StVe9qQT1orv/V1iTtzN2P+L+enXZTHNC32ubdK8Ub3HaMKFhGDu60r/fKKn8OR7TEx9IfHZ UqqhNTjIlb3j49EFl2MDjxxgvJAo9nrt9V4lluKMREMt5qLiRACtZynphQIAAA==
Cc: "" <>
Subject: Re: [secdir] Security review of draft-ietf-pce-questions-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Jul 2014 01:14:39 -0000


	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.


-----Original Message-----
From: ietf [] On Behalf Of Adrian Farrel
Sent: Wednesday, July 09, 2014 4:55 AM
To: 'Ben Laurie'; 'IETF Discussion List';
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.


> 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?