Loa-- I hope this is an appropriate distribution list. If not please forward as necessary. All-- Draft-farrelll-mpls-opportunistic-encrypt-04 specifies the details of a protocol for doing opportunistic encryption of MPLS connections. It permits encryption at any of two scopes: between adjacent Label Switching Routers (LSRs) on an MPLS Label Switched Path (LSP), and/or between end points of an LSP. Opportunistic encryption in this case means that there is no mechanism specified for authenticating the endpoints of the encrypted channel. The two endpoints do an anonymous Diffie-Hellman exchange and use the resulting key to encrypt the connection. The protocol is not protected from a man-in-the-middle attack (though some mechanisms for detecting such an attack after the fact are suggested and a keying infrastructure could be added later). The encryption aspects of the protocol seem well thought out and appropriate. The question at hand is whether to adopt this document as a working group document and it easily meets that bar (at least from a security standpoint). I have a number of questions about operational aspects of the protocol (perhaps due to my limited understanding of MPLS) and I have some suggestions for enhancements that will probably be necessary eventually and might be easier to make before there is widespread deployment: There is an issue that came up in the design of IKEv2 that may be an issue here as well. I don't know whether MPLS connections are bi-directional or whether separate connections need to be established in the two directions. If they are bi-directional, then there are race conditions that can occur if both ends attempt to initialize a connection simultaneously and there must be some tie-breaking mechanism to assure that exactly one of the connection attempts succeeds. If they are uni-directional, and if the connection is always initialized by the sending end, then this is not a problem (though it is replaced with the problem that messages of this protocol sent in the reverse direction cannot be tunneled over the MPLS connection). (This document seems to imply that MPLS connections can be either uni-directional or bi-directional, but I don't understand MPLS well enough to have understood it). Even if the connections are bi-directional, it will make your life simpler if you use different symmetric keys in the two directions. This can be done easily by getting two independent keys from the key expansion process. A second issue relates to algorithm negotiation. While the protocol allows for any of the crypto algorithms to be replaced, and the algorithms are indicated on the wire, it does not appear to allow for a smooth upgrade where the two ends are updated independently and everything must continue to work when only one end has been updated. To accomplish that, there should be an algorithm negotiation (as takes place in IKE and TLS) where one end presents a list of algorithms is can support and the other end chooses the algorithms it prefers. A simpler variation would be for a responder to be able to reject the algorithms assumed by the initiator and send back a list of algorithms it will accept. Note: it's possible that MPLS already operates with the restriction that the two ends of a connection must be consistent and operations will halt if the two ends are updated non-simultaneously. If that's true, then adding crypto doesn't make the situation any worse and it would be acceptable to continue to operate that way. A possible problem with Key Identifiers: the Key Identifier is only 4 bits long, which should be sufficient because at most two keys should be active at any given time. The Key Identifier, however, is chosen effectively randomly, which means that one time in 16 it will be the same as the Key Identifier it is replacing. While the protocol could be modified to do something special in that last (like adding one to the Key Identifier if it matches the previous value or redoing the key negotiation in that case), it would probably be better to get the Key-ID from the key expansion when there is no previous connection and add one (mod 16) when rekeying. There is mention of the possibility of reusing g^i and g^r between connections. Some crypto purists would object to that, but I wouldn't. If you want to allow implementations that option, however, you should also include in the exchange nonce values Ni and Nr that are not reused between connections rather than depending on unique values for the other parameters to prevent reuse of keys. In section 3.5 (MTU considerations), I suspect you may be underestimating the effect on MTU. I believe AES_GCM_128 always adds between 1 and 16 pad bytes to make the encrypted payload size a multiple of 16 bytes. There are algorithm variants that do not add any padding, but they are somewhat controversial and difficult to implement in hardware. Further, the total overhead will be dependent of the crypto algorithm chosen, and the text should indicate that so that readers don't assume that there is some maximum number of bytes that can be wired into protocols that run above this. I would suggest that most or all of sections 5 and 7 should be moved to Security Considerations. Failing that, the Security Considerations section should reference them. Typos: P4: "and if may be advisable" -> "and it may be advisable" P4: "an alternative key derivation functions" -> "alternative key derivation functions" P5: "key definition function" -> "key derivation function" P5: "attck vecotrs" -> "attack vectors" P5: "descirption" -> "description" P19: "opostie" -> "opposite" --Charlie -----Original Message----- From: secdir [ mailto:secdir-bounces at ietf.org] On Behalf Of Loa Andersson Sent: Friday, May 08, 2015 5:24 AM To: secdir; draft-farrelll-mpls-opportunistic-encrypt at tools.ietf.org; mpls-chairs at tools.ietf.org Subject: [secdir] Early review of draft-farrelll-mpls-opportunistic-encrypt Security Directorate, Apologies if I'm sending this too wide! The MPLS wg has a review team. The task of the review team is to support the wg chair, in particular when we are considering a wg adoption poll. Before starting a wg adoption poll we run all documents through the MPLS-RT review (you can find a typical invite to such a review below). Just now we have draft-farrelll-mpls-opportunistic-encrypt in MPLS-RT review. We have enough reviewers accepting to do the review, but all of them have flagged that they are not entirely comfortable reviwing the document from a security perspective. Stephen have very graciously offered to help if there are question. I still would like to ask if it possible to find an expert reviewer in the security directorate. Questions asked are the same as you find in the invite below. Please contact me if you are willing to review the document for us. /Loa mpls wg co-chair -----------example of mpls-rt review invite ----------------------- Dave, Mach, Lizhong and Kamran, You have be selected as MPLS-RT reviewers for draft-farrelll-mpls-opportunistic-encrypt. Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document. Note to the reviewers: I understand that this document is very much on the "security side of the house", however I will also reach out to the Sec-Dir for a more security biased review. This should not stop you from commenting on security aspects of the draft, but if you feel like it I'm comfortable with a "normal MPLS-RT review", responding to questions below. Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound? We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs. If you have technical comments you should try to be explicit about what *really* need to be resolved before adopting it as a working group document, and what can wait until the document is a working group document and the working group has the revision control. Are you able to review this draft by May 17, 2015? Please respond in a timely fashion. Thanks, Loa (as MPLS WG chair) /Loa -- Loa Andersson email: loa at mail01.huawei.com Senior MPLS Expert loa at pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ secdir mailing list secdir at ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview