Subject: [secdir] Review of draft-ietf-pce-path-05

From: "Hilarie Orman" <[email-masked]>
Date: Sun, 7 Dec 2008 18:36:23 -0700

draft-ietf-pce-path-key-05.txt
Preserving Topology Confidentiality in Inter-Domain Path Computation
Using a Key-Based Mechanism

I have re-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 review comments.

I still find it needlessly confusing to name the identifiers, which
are for the purpose of preserving confidentiality, "keys".  This makes
the term "path key expansion" especially jarring to security folks.  I
recommend an editorial change somewhere in the beginning of the
document that explicitly distinguishs path-keys from cryptographic
keys.

A risk that I pointed out in my review of -03, isn't mentioned in
"security considerations": There is a possibility of inferring the
mapping (encoding) if the opaque identifiers are not chosen randomly
or are used for a long time.  Passive observers, over time, might be
able to guess what the idenifiers mean using information that they
obtain independently about network topology and routing patterns.

Hilarie
_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 8 Dec 2008 09:28:39 -0000

Hi Hilarie,

We did see your comments previously, but since they were primarily for the 
security ADs, we did not respond at that time.

> document that explicitly distinguishs path-keys from cryptographic

We can add a sentence to make this clearer for people who might make this 
assumption.

How about...

Please note that the terms "path key" and "key" used in this document refer 
to an identifier allocated by a PCE to represent a segment of a computed 
path. The terms have no relation to the term "cryptographic key" used in 
some documents that describe security issues.

> obtain independently about network topology and routing patterns.

We do not consider that there is any inference that can be drawn except that 
a passive observer might learn how to count! A reasonable implementation 
would simply allocate path keys as monotonic increasing index values.

We could write some apple pie here, but honestly, it is hard to think of a 
way to write an implementation where the path key would have any semantic 
outside a lookup value. We already have text that allows an implementer to 
understand how to verify that the node requesting a path key expansion is 
the node expected to make such a request, so trawling for an expansion 
requires source address spoofing in a way that scales as badly as the number 
of nodes that might need to request expansions. (Such trawling would also 
require that PCEP security was not enabled.)

Cheers,
Adrian

---

From: Russ Housley <[email-masked]>
Date: Mon, 08 Dec 2008 12:20:48 -0500

>Please note that the terms "path key" and "key" used in this 
>document refer to an identifier allocated by a PCE to represent a 
>segment of a computed path. The terms have no relation to the term 
>"cryptographic key" used in some documents that describe security issues.

   s/issues/mechanisms/