Hi Adrian, Joe, Thanks for the review. It will really help in putting the draft in a better shape. We are preparing a new version and the replies below will be reflected there.
On 19 Jan 2014, at 17:37 , Adrian Farrel <[email protected]> wrote: >>> 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. In fact, a first set of ideas on this draft was discussed at the KARP meeting in Berlin. The reference to TCP-AO is derived from that discussion, as there seemed to be a general consensus among the group that TCP-AO should be considered. After this input from you and some other discussions I and the other co-authors have had around, we will focus the discussion on the TLS aspects, and mention TCP protection in general and TCP-AO in particular in the "Security Considerations" section. No interaction between TLS and TCP-AO will be mentioned. >>> 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. The rationale is the common practice derived from the TLS layered approach, so a client knows how and when require the server to start a TLS connection, and the server knows in advance what the client is requiring and match it against its policy. The use of TCP protection must be orthogonal to the use of TLS, so it can not be used for the server making a guess of the protocol security encapsulation. Either we have a protocol-specific mechanism (a-la-STARTTLS) or we use a specific port. The latter implies no changes at all to the protocol, which is included as one of the requirements for secure PCEP exchanges. If adding such a mechanism would be acceptable, we could go for the first option. This is something that should be decided by the WG. I'll update the draft noting this point and highlight it to the WG for discussion. >> >>> 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. Good point. As said above, this will be moved to the Security Considerations section and the TCP-AO deemed out-of-scope, being independent of the TLS usage. >> >>> 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. Agreed. The intertwining of TLS and TCP protection will be eliminated. >> >>> 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. As said above, not using a different port would translate in requiring an additional protocol element, so clients could express their request to start a TLS connection. Going for analyzing a combination of the TCP protection mechanisms would imply the intertwining we are trying to avoid, that translates in the inconsistencies you noted above. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: [email protected] Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
