[Pce] Security directorate review of draft-ietf-pce-interas-pcecp-reqs-03

Hi,

We asked the Security Area Directorate to provide us with an early review of 
draft-ietf-pce-interas-pcep-reqs. Recently, a fair number of I-Ds from PCE 
and CCAMP have been falling at the security hurdle during IESG review. This 
seems to be particularly the case for inter-AS work, so we thought that we 
should try to get some feed-back before we go to WG last call, and see if we 
can produce a draft that better addresses the Security AD's concerns.

We received comments from Sandy Murphy and Pasi Eronen as shown below. The 
chairs will be working with the document authors to revise the text to 
address the issues raised, but we would all be more than grateful for other 
comments and assistance.

Thanks,
Adrian

+++++ <begin Sandy Murphy>

This draft specifies the requirements for a PCE communication
protocol, i.e., a protocol between PCC and PCE or inter-PCE, when the
communication is taking place across AS boundaries.  This AS boundary
could be within one service provider or may be between service
providers.  The PCEs compute paths for the establishment of LSPs
satisfying PCC provided constraints.

This document refers to the security considerations of RFC4657, which
mandates support for protections agains spoofing, snooping and DOS
between the entities.

The example given discusses communication that spans ASs - a PCE1 in
AS1 makes a request of a PCE2 in AS2, who asks a PCE3 in AS3 .  The
reply from AS3 gets augmented by info from the AS2 before PCE2 replies
to PCE1.

This sounded like they anticipate protocols that could lead to
PCE2/AS2 being able to inject bogus information supposedly from AS3
in what it passes to PCE1/AS1 (a la BGP mis-originations).  This is
only an example, but the intent of the protocol is to return the
inter-AS path of the computed LSP, so this behavior is likely.  The
security requirements seem to address only hop-by-hop security - there
are no requirements to ensure that the PCE providing information for
which it is not "authoritative" is providing legitimate info.  I.e.,
there's no end-end model of protecting the data.

The security considerations section also note:

   Additionally, two aspects of operations specific to inter-AS PCEs
   require careful security considerations.  There are two modes of
   determining peering PCEs across the AS boundary manual
   configuration and auto-discovery.  In the manual mode, mechanisms
   for securely exchanging manually confgiured authentication key or
   key sets across SP boundaries MUST be defined.  For example, the
   authentication key May be manually configured for each PCE peer and
   PCE registration MAY be served as a mechanism for securely
   exchanging authentication keys across SP boundaries.  In the
   auto-discovery mode, inter-as PCEs can be auto-discovered only if
   it is configured to participate in that discovery scope.

   An inter-AS PCE is not necessarily able to establish PCEP sessions
   with the discovered PCEs in its scope(s), it MUST be able to
   authenticate with the peering inter-AS PCE, therefore mechanisms
   for securely exchanging authentication keys across SP boundaries
   MUST also be defined in this case.  Furthermore, the auto-discovery
   process itself MUST also be authenticated.

The first paragraph refers to manual and auto-discovery of PCEs and
the problems this creates in an inter-AS situation.  Other pce wg
drafts/RFCs give rough orders of magnitude of 1000s of PCCs
communicating with one PCE and one PCC communicating with 100s of
PCEs.  There's some confusion as to the distinction between PCCs and
PCEs in an inter-PCE communications.  So it is unclear how many
inter-AS inter-PCE connections one PCE might have.  But it does seem
clear that manual keying could be unscalable in inter-PCE
environments.

I do not know what the draft means by saying that PCE registration could
serve to exchange keys across SP boundaries - does it mean in the
initial exchange of open messages?

Auto-discovery mode needs additional consideration.  RFC4674 already
says that an auto-discovery protocol must ensure authenticity,
integrity, and confidentiality, as well as authorization of the PCC.
The present definitions of auto-discovery are extensions on ospf and
isis, but that won't work here.  Seems best to mandate an automated
key management here - perhaps that was the intent of saying "securely
exchanging authentication keys".

        ************************************************************
        Do pay attention to RFC4107  and Sam Hartman's message to the
        wgchairs list reminding them/us of same.
        ************************************************************

Note that RFC4657 also says:

   Key management MUST be provided by the PCECP to provide for the
   authenticity and integrity of PCECP messages.  This will allow
   protecting against PCE or PCC impersonation and also against message
   content falsification.

I don't know that it actually meant to mandate that the PCECP had to
provide key management itself as part of the protocol.  But key
management of some sort is clearly indicated.  It just doesn't say
whether that means manual or automated.

===================================================================

I also took a look at the PCE communication protocol draft.

draft-ietf-pce-pcep-08.txt

This draft's security consideration section does not refer to the
security considerations section of RFC4657 (PCEP generic requriements),
which mandates that

   The PCC-PCE communication protocol MUST include provisions to ensure
   the security of the exchanges between the entities.  In particular,
   it MUST support mechanisms to prevent spoofing (e.g.,
   authentication), snooping (e.g., preservation of confidentiality of
   information through techniques such as encryption), and Denial of
   Service (DoS) attacks (e.g., packet filtering, rate limiting, no
   promiscuous listening).  Once a PCC is identified and authenticated,
   it has the same privileges as all other PCCs.

This draft does not mandate any authentication mechanism.  It does
RECOMMEND use of TCP-MD5.

        ************************************************************
        Note: TCP-MD5 is technically weak.  It's use in BGP required
        a special process exception.  It is unlikely such an exception
        would be granted to a new use.
        ************************************************************

It would appear that this draft and RFC4657 are referring to
hop-by-hop security only.

Note: PCEP runs over TCP.  It adopts the severe response model BGP
uses -- it terminates a session if a mal-formed message appears or
the TCP connection fails.  This means it is susceptible to TCP
off-path guesses at sequence numbers leading to RSTs or out-of-order
data being accepted.  I don't think a TLS/SSL level protection would
protect the protocol.

This draft differentiates behavior on receipt of some messages (e.g.,
NOTIFICATION) depending on whether the sender was a PCC or a PCE.  I
don't see that the PCC/PCE difference is communicated anywhere.  The
draft usually speaks only of PCC-PCE communication, not inter-PCE
communication.  However, RFC4674 notes that it (the rfc) makes no
distinction between a PCC and a PCE acting as a PCC (because it was
making a request inter-PCE).  The same may be here also, so it may be
possible that the role of the peer is maintained in connection
state.  But it is not clear that the PCE peers in the connection don't
take on both PCC and PCE roles over time, so I'm not positive that
helps.

===================================================================

I also took a look at:

rfc4674 (Requirements for PCE Discovery)

This RFC says:

   It is also important to note that the notion of a PCC encompasses a
   PCE acting as PCC when requesting a path computation of another PCE
   (inter-PCE communication).  Hence, this document does not make the
   distinction between PCE discovery by PCCs and PCE discovery by PCEs.

The rest of the text refers to PCCs discovering PCEs, without
distinguishing whether these are the "real" PCCs or PCEs acting as
PCCs.  This makes it difficult to determine the usual operational
model for inter-AS discovery: do "real" PCCs discover the PCEs who are
inter-AS capable in their own domain so that the inter-AS PCE can then
discover the inter-AS PCE in a neighboring AS, or can a "real" PCC
directly discover the remote ASs inter-AS PCE?  The difference could
make a difference in deciding on the scaling needed in a key
management scheme.

Note that the rfc gives order of magnitude of what the discovery
design must support:

   - Number of PCCs discovering a given PCE: 1000
   - Number of PCEs to be discovered by a given PCC: 100

But it is unclear if these are the "real" PCCs or includes PCEs that
are acting as PCCs

   The PCE discovery mechanism MUST allow for policies to restrict the
   discovery scope to a set of authorized domains, to control and
   restrict the type and nature of the information to be disclosed, and
   also to filter and translate some information at domains borders.

   Such inter-AS PCE discovery must be carefully controlled.  For
   security and confidentiality reasons, particularly in an inter-
   provider context, the discovery mechanism MUST allow the discovery
   scope to be limited to a set of ASs and MUST also provide control of
   the PCE information to be disclosed across ASs.  This is achieved by
   applying policies (see also Section 4.4).  This implies the
   capability to contain a PCE advertisement to a restricted set of one
   or more ASs, and to filter and translate any PCE parameter (PCE
   domains, PCE inter-domain functions, PCE capabilities, etc.) in
   disclosures that cross AS borders.

These references to translation are probably intended to apply in cases
like the example given: "translate" what is communicated internally to
something else when communicated externally.

But other references make it sound like some of the discovery information
might come from another domain down the line:

   Also the PCE discovery mechanism MUST allow discovery of the inter-
   domain functions of a PCE, i.e., whether a PCE can be used to compute
   or to take part in the computation of end-to-end paths across domain
   borders.  The inter-domain functions include nonexhaustively: inter-
   area, inter-AS and inter-layer path computation.  Note that these
   functions are not mutually exclusive.

   Note that the inter-domain functions are not necessarily inferred
   from the set of domains where a PCE has visibility.  For instance, a
   PCE may have visibility limited to a single domain, but may be able
   to take part in the computation of inter-domain paths by
   collaborating with PCEs in other domains.

In such a case, "translating" information starts to sound more
troubling - it could be "translating" information which came from some
other domain.  The hop-by-hop integrity protections would be useless
against changes made by the peer PCE.

+++++ <end Sandy Murphy>

+++++ <begin Pasi Eronen>

I was assigned to do an early Security Directorate review of
draft-ietf-pce-interas-pcecp-reqs-03 ("Inter-AS Requirements for
the Path Computation Element Communication Protocol (PCECP)").

This is certainly one of the most difficult SecDir review
assignments I've gotten so far. The document itself is only 13
pages, but it required quite a lot of background reading; and the
security issues seem to span a rather large set of documents, none
of which can be fully considered alone.

So, a disclaimer is in order: I'm not very familiar with the topic
area (PCE, MPLS), and this review is in no sense thorough or
exhaustive.

In general, the documents seem rather well written, and consider
security broadly (not just cryptographic mechanisms for protecting
messages, but also e.g. revealing sensitive information to
authenticated communication nodes, etc.).

However, I identified at least the following topics that IMHO
require further clarification:

1) Interaction between PCE discovery and PCEP communication security

It looks like there's a rather large disconnect between the PCE
discovery drafts (which assumes that PCCs can dynamically and
automatically discover PCEs) and the actual PCE protocol document
(which uses communication security mechanisms that essentially
require manual configuration of each PCC-PCE relationship).

Or in other words: if you use TCP-MD5, and anyway have to manually
configure the shared secrets and PCC/PCE IP addresses at each
PCE/PCC, the benefits of having a discovery mechanism are quite
limited (the capability part might still be useful, though).

Using something else than TCP-MD5, such as IPsec, does not
fundamentally change the situation. If you use shared secrets
(that are really pairwise shared secrets, and not shared by all
devices in a domain), they need pairwise configuration. Some
kind of PKI might reduce the configuration work from O(N^2)
to O(N), but that has challenges, too.

2) PCE discovery/communication security, inter-AS case

The previous issue is likely to be more complex in the inter-AS
case.

The interas-pcep-reqs draft basically states that "mechanisms for
securely exchanging manually configured authentication key ...
across SP boundaries MUST be defined". However, it's not clear
whether this mechanism is intended to be (or even can be) purely
a network protocol, or whether it's more a "ceremony" or
"procedure" involving off-line human interaction.

Or in other words: is the intent to define, for example, a key
management protocol for TCP-MD5 (possibly based on existing
security relationships in e.g. BGP or IGP)? Or something else
completely?

3) Use of TCP-MD5

The PCEP draft specifies TCP-MD5 as the recommended security
mechanism.  I am not, at this time, suggesting that it would be
better to use X instead -- but it's probable that some else will,
and that any new protocol attempting to use TCP-MD5 will raise
some questions. At least a good explanation is likely to be required.

4) IPsec details

The PCEP draft basically says that IPsec MAY be used.  This
is nowhere near enough; see e.g. draft-bellovin-useipsec-06
for a starting point.

5) PCE policies vs. message authentication

One topic that has received relatively little discussion is the
relationship of policies based on the identity or other attributes
(such as AS) of a PCC, and the cryptographic mechanisms for
authenticating messages. The challenge is that the policy at
the PCE might be expressed in terms of identifiers/properties
of PCC that are not readily supplied (or authenticated) by the
PCC-PCE message authentication mechanism.

For example, if a PCE configures TCP-MD5 key to protect all
messages coming from 192.0.2.1 with key "secret", it would be
straightforward to have a PCE policy "for requests coming from
PCC 192.0.2.1, avoid paths with (some criteria)".

However, a policy "for requests coming from Example Operator Inc.,
avoid paths with..." (or "...coming from AS 1234...") would require
additional information (possibly via manual configuration) to
determine how the request should be processed (e.g., mapping
authenticated PCC identity to the identifier/property used in the
policy in a secure fashion).

Such a manual configuration is certainly doable -- especially in
case where all the other information (such as shared secrets) is
manually configured as well -- but is slightly more problematic if
PKI-based authentication is envisioned. If the certificate doesn't
contain the identifiers/properties you need, per-PCC manual
configuration might still be needed. This may also limit the types
of policies you can easily use.

6) Policies in different PCEs and verifying correct operation

One important manageability consideration in RFC 4655 is verifying
correct operation, in particular assessing the validity of the
computed paths.  This is likely to be especially challenging in
inter-AS case, as any single operator does not necessarily have
management access to all the PCEs involved in a computation.

This is further complicated by inter-AS rewriting/reinterpretation of
parameters, constraints, and policies. Such rewriting/reinterpretation
could also include malicious intent, and thus may be a security issue.

+++++ <end Pasi Eronen> 

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce