Re: [secdir] review of draft-ietf-pce-pcep-domain-sequence-09

[Dhruv Dhody <[e-mail]>]

Hi Klaas,

Thank you for your review and sorry for the delay in the reply [ Diwali
festivities in these neck of woods :) ]
Please see inline...

On Mon, Nov 9, 2015 at 9:10 PM, Klaas Wierenga (kwiereng) <
[e-mail]> wrote:

> Hi,
>
> I have reviewed this document 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.
>
> I consider the document “ready with issues”, see below for detailed
> comments:
>
> * 4.1 Inter-Area Path Computation
>
> you write: "This could be represented in the IRO as:” and then a number of
> diagrams. It is unclear to me whether those different option are
> functionally equivalent. The text suggests so to me, but that doesn’t seem
> to make sense….. (or I completely misunderstand the text)
>
> To me it seems that the three sequences you give are all possible
> sequences for the given topology not equivalent, I think the text needs
> some clarification in that case.
>
> The same goes for 4.2, 4.3 etc.
>
>
​[Dhruv]: They are equivalent in the sense that if the source is in Area 2,
destination in Area 4 and transit through Area 0, a PCC can encode the IRO
in any of these combinations to get the same result. I can add
clarification to make it clearer. ​



>
> * 4.5 P2MP
>
> I am guessing that the tree you show is the result of the three paths you
> give before, but some explanation would be good.
>
>
​[Dhruv]: Ok, i can use the same example as
https://tools.ietf.org/html/rfc7334#section-7.2 and add some more text
here. ​



> 7 security considerations
>
> I think these are a bit weak. Especially compared to what RFC5440
> provides. I consider an attacker gaining fine grained control over the
> network path a very serious risk. The flippant comment about “routing
> around trouble” doesn’t really do it for me. I would encourage you to take
> a good look at the security considerations in 5440 and assess how those
> considerations change given the finer grained control you provide. Some or
> even most may remain the same, and it is fine to say so, but I can imagine
> that some risks are higher because of the fine-grained control, and you
> seem to suggest so too given the “the security techniques in rfc5440 are
> considered more important”. So I really think this draft would benefit from
> a better security considerations section.
>

​[Dhruv]: Here is the updated text, let me know if you would like to see
any changes. Text would be extra helpful. ​

​7.  Security Considerations

   The protocol extensions defined in this document do not substantially
   change the nature of PCEP.  Therefore, the security considerations
   set out in [RFC5440] apply unchanged.  Note that further security
   considerations for the use of PCEP over TCP are presented in
   [RFC6952].

   This document specifies a representation of Domain-Sequence and new
   subobjects, which could be used in inter-domain PCE scenarios as
   explained in [RFC5152], [RFC5441], [RFC6805], [RFC7334] etc.  The
   security considerations set out in each of these mechanisms remain
   unchanged by the new subobjects and Domain-Sequence representation in
   this document.

   But the new subobjects do allow finer and more specific control of
   the path computed by a cooperating PCE(s).  Such control increases
   the risk if a PCEP message is intercepted, modified, or spoofed
   because it allows the attacker to exert control over the path that
   the PCE will compute or to make the path computation impossible.
   Consequently, it is important that implementations conform to the
   relevant security requirements of [RFC5440].  These mechanisms
   include:

   o  Securing the PCEP session messages using TCP security techniques
      (Section 10.2 of [RFC5440]).  PCEP implementations SHOULD also
      consider the additional security provided by the TCP
      Authentication Option (TCP-AO) [RFC5925] or [PCEPS].

   o  Authenticating the PCEP messages to ensure the message is intact
      and sent from an authorized node (Section 10.3 of [RFC5440]).

   o  PCEP operates over TCP, so it is also important to secure the PCE
      and PCC against TCP denial-of-service attacks.  Section 10.7.1 of
      [RFC5440] outlines a number of mechanisms for minimizing the risk
      of TCP-based denial-of-service attacks against PCEs and PCCs.

   o  In inter-AS scenarios, attacks may be particularly significant
      with commercial as well as service-level implications.

   Note, however, that the Domain-Sequence mechanisms also provide the
   operator with the ability to route around vulnerable parts of the
   network and may be used to increase overall network security.​

​Thank you for your review.

The working copy diff is attached for reference (includes IANA, Gen-ART,
Sec-Dir reviews).

Regards,
Dhruv​



>
> Hope this helps,
>
> Klaas
>
> --
> Klaas Wierenga
> Identity Architect
> Cisco Cloud Services
>
>
>
>
>
>
>