Hi, With half an eye on Diego's draft I asked in the Transport Area for some advice and expertise from that community, and Joe Touch stepped forward.
Bearing in mind that Joe may not be the PCE expert that some of you are, here are his comments on the use of TCP security in PCEP. Double quote is me, and then later Diego's draft. Single quote is Joe. Thanks to Joe for his time. Please be sure to copy him directly on any discussions so that he can see them without subscribing to the PCE list. Cheers, Adrian > > The PCE WG has http://datatracker.ietf.org/doc/draft-lopez-pce-pceps/ which > > is about running PCEP (the PCE protocol, a TCP-using protocol) using TLS and > > TCP-AO. > > > > We could look at the work done in KARP (RFC 6952) but that is hardly conclusive. > > That work was driven largely by that WG's concern with the lack of > availability of a TCP-AO implementation in end-system OSes (Linux or > FreeBSD). They spent an inordinate amount of time complaining about > that, time that could easily have been used to implement the protocol > rather than worrying about alternate interim solutions. > > > The base PCEP spec (RFC 5440) pre-dated the > > publication of TCP AO, but did include a forward pointer. > > ------------------------------------------- > > Secure Transport for PCEP > draft-lopez-pce-pceps-00 > > > 2.1. TCP ports > > > > The default destination port number for PCEPS is TCP/XXXX. > > > > NOTE: This port has to be agreed and registered as PCEPS with IANA. > > PCEP already is assigned to port 4189. RFC5440 already permits PCEP > connections to use either TCP MD5 or TCP-AO, but at the time of that > document there was no TCP-AO to reference. > > As a result it should be trivial for a PCEP server to differentiate pcep > vs. pceps connections: > > MD5 must be pcep, and already don't use TLS > > TCP-AO must be pceps, and thus must include TLS > > connections using neither MD5 nor TCP-AO must be pceps, > and thus must include TLS > > I don't see a rationale for needing a separate port. > > > 2.2. TLS Connection Establishment > ... > > NOTE: We have to consider potential interactions between TLS re- > > negotiation and TCP-AO MKT > > I don't understand this statement. TLS has nothing to do with TCP-AO; > TCP-AO's protection does not modify the application (TLS) view of TCP at > all (even if keys change during a connection). > > There should be no interaction. > > > 2.3. TCP-AO Application > > > > PCEPS implementations MAY in addition apply the mechanisms described > > by the TCP Authentication Option (TCP-AO, described in [RFC5925] to > > provide an additional level of protection with respect to attacks > > specifically addressed to forging the TCP connection underpinning > > TLS. TCP-AO is fully compatible with and deemed as complementary to > > TLS, so its usage is to be considered as a security enhancement > > whenever any of the PCEPS peers require it.' > > I don't understand the rational for the protection defined by PCEPS vs PCEP. > > PCEP = *requires* TCP protection (either TCP MD5 or IPsec), but allows > privacy to be optional (e.g., when using TCP MD5); regardless of the > forward pointer to TCP-AO, there was no specification to cite, thus it > cannot be required. > > PCEPS = *requires* privacy by TLS, but leaves TCP protection as optional. > > This makes no sense to me. IMO, TCP protection *must* be mandatory, or > RFC5440 needs to be updated before PCEPS should proceed. > > > Implementations including support for TCP-AO MUST provide mechanisms > > to configure the requirements to use TCP-AO, as well as the > > association of a TCP-AO Master Key Tuple (MKT) with a particular > > peer. > > The above is a strange way to say "implementations supporting TCP-AO > MUST support TCP-AO", which is a tautology that need not be stated. > > > Whether these mechanisms are provided by the administrative > > interface or rely on the TLS handshake according to procedures > > similar to those described in [RFC5216] and [RFC5705] is outside the > > scope of this document. > > TLS cannot be used to protect TCP-AO sessions. For a given connection, > TCP-AO must be started at connection establishment, which is prior to > TLS negotiation. > > ... > > > 4. Backward Compatibility > > > > Since the procedure described in this document describes a security > > container for the transport of PCEP requests and replies carried on a > > newly allocated TCP port there will be no impact on the base PCEP > > and/or any further extensions. > > See my comment above; I agree, but not because a new port is needed. > > > 5. IANA Considerations > > > > NOTE: PCEPS has to be registered as TCP port XXXX. > > > > No new PCEP messages or other objects are defined. > > As noted earlier, I disagree with this requirement. > > > 6. Security Considerations > > > > Since computational resources required by TLS handshake and > > ciphersuite are higher than unencrypted TCP, clients connecting to a > > PCEPS server can more easily create high load conditions and a > > malicious client might create a Denial-of-Service attack more easily. > > FWIW, the same is true for IPsec and TCP-AO (at best only IPsec might > have hardware support). > > --- > > Missing - the doc needs to specify which parameters to use for TCP-AO, > from among those listed in RFC5926. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
