Eric Rescorla has entered the following ballot position for draft-ietf-trill-over-ip-15: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hopefully this is easy to resolve. In the best case, you will be able to demonstrate that this is not a problem in practice and document that. If not, the actual fix is straightforward, though incompatible. S 7.1.1. I am concerned about the use of the IS-IS key in this way. First, on general principles, you should not use a single key both as input to a KDF and directly as a working key. Specifically, however, RFC 5310 defines the use of HMAC authentication with IS-IS-key as the HMAC key, and HKDF-Expand is really just SHA-256. Thus, if an attacker was able to observe (or cause to be created) an IS-IS packet that happened to have the same contents as the HKDF Info value you provide would then know the IKE PSK. The correct practice here is to separately expand both the IS-IS key *and* the IKE PSK from the same original value. If you cannot do that, you should at least generate an Info value which is guaranteed to not be the input to any RFC 5310 MAC. When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that incorporates the IS-IS shared key in order to bind the TRILL data session to the IS-IS session. The pre-shared key that will be used The technique you provide does not guarantee a binding between the sessions. It merely ensures (modulo the caveat above) that both sides know the IS-IS Key. It's easy to see this by noting that you could move IS-IS traffic from one IPsec association to another. If you actually want to bind these sessions, you must do something different. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I see that native encapsulation is incompatible with NATs (S 8). That's probably worth stating upfront to minimize confusion. S 5.4.2. f. No middleboxes are allowed in the TRILL over IP transport link because middlebox support is beyond the scope of this document. How would you know if no middleboxes were in the link? S 5.5. Can you use VXLAN with IPsec? S 5.6. What security mechanism do you expect to use for TCP? IPsec again? the timing and implementation details may be such that P! and P2 each Nit: P1, right? _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill