Re: [secdir] secdir review of draft-ietf-pce-wson-routing-wavelength-14

[Leeyoung <[e-mail]>]

Hi Dan,

Thanks. We will address PCEP security mechanisms in the solution draft. We will also factor in Oscar's suggestion in this thread.

Best regards,
Young

-----Original Message-----
From: Dan Harkins [mailto:[e-mail]] 
Sent: Tuesday, October 28, 2014 11:25 AM
To: Leeyoung
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: secdir review of draft-ietf-pce-wson-routing-wavelength-14


  Hi Young,

On Tue, October 28, 2014 8:50 am, Leeyoung wrote:
> Hi Dan,
>
> Thanks a lot for your review and providing comments.
>
> Would the following work for you in Security Section to add:
>
> "Solutions that address the requirements in this document need to 
> verify that existing PCEP security mechanisms adequately protect the 
> additional network capabilities and must include new mechanisms as necessary."

  Yes, that's fine. Adrian had a good point (it's a requirements document) and this puts the requirements where they should be-- on the solution that addresses the requirements.

  thanks,

  Dan.

> Best regards,
> Young
>
> -----Original Message-----
> From: Dan Harkins [mailto:[e-mail]]
> Sent: Monday, October 27, 2014 12:04 PM
> To: [e-mail]; [e-mail];
> [e-mail]
> Subject: secdir review of draft-ietf-pce-wson-routing-wavelength-14
>
>
>   Hello,
>
>   I have reviewed draft-ietf-pce-wson-routing-wavelength as part of 
> the security directorate's ongoing effort to review all IETF documents 
> being processed by the IESG.  These comments were written primarily 
> for the benefit of the security area directors. Document editors and 
> WG chairs should treat  these comments just like any other last call comments.
>
>   This is a requirements document for additions to the PCEP protocol 
> to support path computation in a wavelength-switched optical network. 
> It describes what needs to be added to requests/responses to support 
> routing and wavelength assignment to a path computation element (that 
> supports both functions) for a path computation client.
>
>   The security considerations are basically a punt. There's 
> information that an operator may not want to disclose and 
> "[c]onsideration should be given to securing this information." That 
> seems a little thin. At the very least some explanation of how this 
> should be done. Do only the TLVs that represent these required additions require confidentiality?
> Is KARP a potential solution to this problem? If so it might be nice 
> to explain that; if not, then why and what else would be required?
>
>   It is a well-organized and well-written document. I would say it is 
> "ready with nits", my nits being the thinness of the Security 
> Consideration section.
>
>   regards,
>
>   Dan.
>
>
>