Subject: [secdir] Secdir review of draft-ietf-pce-global-concurrent-optimization-10.txt

From: Charlie Kaufman <[email-masked]>
Date: Sun, 5 Apr 2009 21:32:40 -0700

I am reviewing 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. Feel free to forward to any appropriate forum.

This I-D defines some extensions to the protocol defined in RFC 5440, and since those extensions do not affect the security sensitivity of the protocol in any significant way, the document appropriately refers to that one for Security Considerations.

That said, the Security Considerations section of RFC 5440 is somewhat dubious. It requires that implementations of this protocol MUST support TCP-MD5 (RFC 2385) as a security mechanism, with recommendations that they implement TCP-AUTH when it becomes available. It notes that TLS and IPsec might be preferable at some point in the future if key management issues can be resolved. TCP-MD5 (and its successor TCP-AUTH/TCP-AO) were developed to solve some specialized problems associated with BGP - in particular, the ability to maintain a TCP connection for an indefinite period (often counted in years) surviving reboots of the endpoints. Its keying is manual, which quickly becomes unworkable as the number of endpoints rises. In response, it is common to use group keys (where the same key is used to protect all of the connections within a realm). TCP-MD5 also provides no confidentiality of data, in spite of the fact that this I-D says the data carried by this protocol may be somewhat sensitive.

This reviewer believes that TLS or IPsec would have been a better choice (and given the current state of the world, TLS would be the better of the two), and that the developers of this protocol should consider supporting one of those in the future. Manual keying could still be used with those protocols, though it would be better to issue certificates to the various endnodes. These certificates need not (and perhaps should not) chain to a commercial root; they could be issued by the same administrators who today configure the shared keys.

But... there is no reason to hold up approval of the updates in this document. Protecting the protocol by authenticating the endpoints and protecting the integrity of the data seems both necessary and sufficient; I don't see any need to include any other forms of security analysis.

=====
I found the following minor (typo-level) issues:

p4 para 4 line 8: distributed -> distributing
p4 para 5 line 6: promote -> promotes
p5 para 2 line 10: preemption -> ??? (**I suspect you didn't mean preemption, but I can't guess what word you meant)
p9 para 3 line 1: regards -> regard
p10 para 1 line 7: LSP -> LSPs (**though perhaps some different wording change would be better)
p15 section 5.2 line 3: computation -> computations
p18 defn MU line 2: all link -> all links
p18 defn mU line 2: all link -> all links

There are several places (beginning with section 5.4 defn Type) which read "To be defined by IANA (suggested value = 5)". Unless there are multiple revisions to this protocol going on in parallel (such that the values assigned might depend on the order in which the documents are advanced), I believe the normal protocol is for an I-D to just specify the new value and repeat it in the IANA considerations section (which this document does). That will minimize work for the RFC editor.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 6 Apr 2009 13:41:50 +0100

Hi Charlie,

Thanks for your detailed review.

Wrt the security section in 5440, this text was arrived at after quite a lot
(understatement) of debate with the SecDir and Security ADs. We in the PCE
working group are not security experts, but we were able to represent that
the TCP relationships are of a similar order of magnitude to those used in
BGP. On the strength of this, the recommendations in the Security
Considerations section were drawn up and agreed.

With respect to the typos (I'm responding so the document Editor can be
clear what to do - Young, please wait until you do an update after IESG
review)

> p4 para 4 line 8: distributed -> distributing

"distributed" is correct.

> p4 para 5 line 6: promote -> promotes

Yes

> p5 para 2 line 10: preemption -> ??? (**I suspect you didn't
> mean preemption, but I can't guess what word you meant)

Agree that the sentence is suffering from lack of context, but preemption
was meant.

OLD
   Note
   that other preemption can also help reducing the fragmentation
   issues.
NEW
   Note that other techniques, including LSP preemption, can also be uused
to
   help reduce the fragmentation issues within the network.

> p9 para 3 line 1: regards -> regard

Leave it for the RFC Editor to decide which is correct US English.

> wording change would be better)

Agree
OLD
   This scenario assumes that the
   bandwidth of existing TE LSP is kept during the migration which is
   required in optical networks.
NEW
   This scenario assumes that the
   bandwidth of existing TE LSPs remains the same during the migration
   steps: something that is required in optical networks.

> p15 section 5.2 line 3: computation -> computations

Yes

> p18 defn MU line 2: all link -> all links

Yes

> p18 defn mU line 2: all link -> all links

Yes

> There are several places (beginning with section 5.4 defn Type) which read
> "To
> be defined by IANA (suggested value = 5)". Unless there are multiple
> revisions
> to this protocol going on in parallel (such that the values assigned might
> depend
> on the order in which the documents are advanced), I believe the normal
> protocol
> is for an I-D to just specify the new value and repeat it in the IANA
> considerations
> section (which this document does). That will minimize work for the RFC
> editor.

There are several PCEP I-Ds in the pipeline at the same time.
Suggested values help the RFC Editor coordinate these documents, but
allocaiton is strictly the purview of the IANA.

Cheers,
Adrian

----- Original Message ----- 
From: "Charlie Kaufman" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
"[email-masked]" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, April 06, 2009 5:32 AM
Subject: Secdir review of
draft-ietf-pce-global-concurrent-optimization-10.txt

I am reviewing 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. Feel free to forward to any appropriate
forum.

This I-D defines some extensions to the protocol defined in RFC 5440, and
since those extensions do not affect the security sensitivity of the
protocol in any significant way, the document appropriately refers to that
one for Security Considerations.

That said, the Security Considerations section of RFC 5440 is somewhat
dubious. It requires that implementations of this protocol MUST support
TCP-MD5 (RFC 2385) as a security mechanism, with recommendations that they
implement TCP-AUTH when it becomes available. It notes that TLS and IPsec
might be preferable at some point in the future if key management issues can
be resolved. TCP-MD5 (and its successor TCP-AUTH/TCP-AO) were developed to
solve some specialized problems associated with BGP - in particular, the
ability to maintain a TCP connection for an indefinite period (often counted
in years) surviving reboots of the endpoints. Its keying is manual, which
quickly becomes unworkable as the number of endpoints rises. In response, it
is common to use group keys (where the same key is used to protect all of
the connections within a realm). TCP-MD5 also provides no confidentiality of
data, in spite of the fact that this I-D says the data carried by this
protocol may be somewhat sensitive.

This reviewer believes that TLS or IPsec would have been a better choice
(and given the current state of the world, TLS would be the better of the
two), and that the developers of this protocol should consider supporting
one of those in the future. Manual keying could still be used with those
protocols, though it would be better to issue certificates to the various
endnodes. These certificates need not (and perhaps should not) chain to a
commercial root; they could be issued by the same administrators who today
configure the shared keys.

But... there is no reason to hold up approval of the updates in this
document. Protecting the protocol by authenticating the endpoints and
protecting the integrity of the data seems both necessary and sufficient; I
don't see any need to include any other forms of security analysis.

=====

p4 para 4 line 8: distributed -> distributing
p4 para 5 line 6: promote -> promotes
p5 para 2 line 10: preemption -> ??? (**I suspect you didn't mean
preemption, but I can't guess what word you meant)
p9 para 3 line 1: regards -> regard
p10 para 1 line 7: LSP -> LSPs (**though perhaps some different wording
change would be better)
p15 section 5.2 line 3: computation -> computations
p18 defn MU line 2: all link -> all links
p18 defn mU line 2: all link -> all links

There are several places (beginning with section 5.4 defn Type) which read
"To be defined by IANA (suggested value = 5)". Unless there are multiple
revisions to this protocol going on in parallel (such that the values
assigned might depend on the order in which the documents are advanced), I
believe the normal protocol is for an I-D to just specify the new value and
repeat it in the IANA considerations section (which this document does).
That will minimize work for the RFC editor.

---

From: Charlie Kaufman <[email-masked]>
Date: Mon, 6 Apr 2009 10:38:25 -0700

>Considerations section were drawn up and agreed.

I suspected something like that happened, and I didn't intend to criticize
the authors of RFC5440 (and certainly not of this I-D). It was more an
invitation to the security directorate to consider the role of TCP-MD5
vs. TLS or IPsec in future protocols. TCP-AUTH should either be advanced
as a general purpose lightweight replacement or it should be limited to
uses where backward compatibility is an issue. (I believe the latter would
be more appropriate). Today its status is more ambiguous.

	--Charlie

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Monday, April 06, 2009 5:42 AM
To: Charlie Kaufman; Young Lee
Cc: secdir; [email-masked]; [email-masked]; [email-masked]; Dan King; Eiji Oki; Adrian Farrel
Subject: Re: Secdir review of draft-ietf-pce-global-concurrent-optimization-10.txt

Hi Charlie,

Wrt the security section in 5440, this text was arrived at after quite a lot
(understatement) of debate with the SecDir and Security ADs. We in the PCE working group are not security experts, but we were able to represent that the TCP relationships are of a similar order of magnitude to those used in BGP. On the strength of this, the recommendations in the Security Considerations section were drawn up and agreed.

With respect to the typos (I'm responding so the document Editor can be clear what to do - Young, please wait until you do an update after IESG
review)

Yes

> preemption, but I can't guess what word you meant)

Agree that the sentence is suffering from lack of context, but preemption was meant.

OLD
   Note
   that other preemption can also help reducing the fragmentation
   issues.
NEW
   Note that other techniques, including LSP preemption, can also be uused to
   help reduce the fragmentation issues within the network.

Agree
OLD

Yes

Yes

Yes

> There are several places (beginning with section 5.4 defn Type) which 
> read "To be defined by IANA (suggested value = 5)". Unless there are 
> multiple revisions to this protocol going on in parallel (such that 
> the values assigned might depend on the order in which the documents 
> are advanced), I believe the normal protocol is for an I-D to just 
> specify the new value and repeat it in the IANA considerations section 
> (which this document does). That will minimize work for the RFC 
> editor.

There are several PCEP I-Ds in the pipeline at the same time.
Suggested values help the RFC Editor coordinate these documents, but allocaiton is strictly the purview of the IANA.

Cheers,
Adrian

----- Original Message -----
From: "Charlie Kaufman" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>; "[email-masked]" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, April 06, 2009 5:32 AM
Subject: Secdir review of

=====

---

From: Sam Hartman <[email-masked]>
Date: Mon, 13 Apr 2009 11:08:59 -0400

>>>>> "Charlie" == Charlie Kaufman <[email-masked]> writes:
s section were drawn up and agreed.

    Charlie> I suspected something like that happened, and I didn't
    Charlie> intend to criticize the authors of RFC5440 (and certainly
    Charlie> not of this I-D). It was more an invitation to the
    Charlie> security directorate to consider the role of TCP-MD5
    Charlie> vs. TLS or IPsec in future protocols. TCP-AUTH should
    Charlie> either be advanced as a general purpose lightweight
    Charlie> replacement or it should be limited to uses where
    Charlie> backward compatibility is an issue. (I believe the latter
    Charlie> would be more appropriate). Today its status is more

I'd strongly encourage the security community to work with the routing
community to make a recommendation for new routing protocols.  I think
there is general agreement in the transport and security community
that the factors that make TCP-AO necessary for BGP are a mistake and
that we regret the situation although we agree that fixing it is too
expensive.
I suspect this belief is not shared in the routing area.

If I were going to tilt at that windmill I'd try to start by building
a consensus that you want to decouple upper layer session state from
transport session state: the idea that I have a huge flap when I get a
TCP RST is not something we want to do in future protocols.  Then I'd
try and build consensus behind GTSM+TLS in an integrity only mode as a
security solution for new protocols in the routing area that smell
like BGP in their transport characteristics (two-parties, traditional
transport connection, no multicast).  You'd need to be very careful
not to be accused of requiring a PKI--self signed certificates,
anonymous DH or PSK would be about as much as you could require.
Obviously, if someone wanted a PKI, such a protocol could work with
that too, but I think requiring or implying a PKI would be viewed as a
fatal flaw.

>From this starting point it would not hugely surprise me if there were
constraints I didn't understand that lead you back to TCP-AO.

If you do start down that path, keep in mind:

* Concerns about using IPsec, including configuration difficulty,
  complexity of things like use-ipsec, and implementation
  problems. Remember Bryan's saag presentation.
* The routing community considers needing to talk to OCSP, CRLDPs,
  SCVP, third parties of any kind really bad when bringing up the
  routing system.
* DOS concerns are huge.

There are also a lot of political issues.