Hi Tobias, that works for me, thank you.
Regards, Valery. > Hey Valery, > Thanks for the explanation. I added the following statement to the security > considerations. Could you > please let me know if that resolves your concerns? > > As the IV MUST NOT repeat for one SPI when Counter-Mode ciphers are > used, Implicit IV as described in this document MUST NOT be used in > setups with the chance that the Sequence Number overlaps for one SPI. > Multicast as described in [RFC5374], [RFC6407] and > [I-D.yeung-g-ikev2] is a prominent example, where many senders share > one secret and thus one SPI. Section 3.5 of [RFC6407] explains how > repetition MAY BE prevented by using a prefix for each group member, > which could be prefixed to the Sequence Number. Otherwise, Implicit > IV MUST NOT be used in multicast scenarios. > > Thanks > Tobias > > -----Ursprüngliche Nachricht----- > Von: Valery Smyslov [mailto:[email protected]] > Gesendet: Donnerstag, 20. Oktober 2016 10:16 > An: 'Tobias Guggemos' <[email protected]>; 'Daniel Migault' > <[email protected]>; 'IPsecME WG' <[email protected]> > Betreff: RE: [IPsec] FW: New Version Notification > fordraft-mglt-ipsecme-implicit-iv-01.txt > > Hi Tobias, > > > Hey Valery, > > Thanks for the clarification, we'll add this statement in the draft! > > Thank you. > > > Just because I'm interested: For me, this seems to be a general > > problem for implementing counter > ciphers > > in multicast scenarios, regardless of implicit-iv or not. > > Do you know how the IV is usually chosen in multicast-implementations? > > The Group Controller assigns each sender a unique counter prefix. See Section > 3.5 of RFC 6407. > > Regards, > Valery. > > > Maybe we could add a recommendation in the draft. > > > > Thanks > > Tobias > > > > > > > > -----Ursprüngliche Nachricht----- > > Von: IPsec [mailto:[email protected]] Im Auftrag von Valery > > Smyslov > > Gesendet: Montag, 10. Oktober 2016 09:06 > > An: Daniel Migault <[email protected]>; IPsecME WG > > <[email protected]> > > Betreff: Re: [IPsec] FW: New Version Notification > > fordraft-mglt-ipsecme-implicit-iv-01.txt > > > > Hi Daniel, > > > > I think you should add a text in the Security Considerations that > > these transforms MUST NOT be > used in > > situations where there is a chance that Sequence Numbers repeat. The > > most prominent example where > it > > can happen - multicast ESP SA with multiple senders. > > > > Regards, > > Valery. > > > > > > > Hi, > > > > > > Based on the feed backs and the discussions from the previous IETF, > > > see the updated version of our draft. We believe the document is in > > > good > > shape to become a WG document. > > > > > > Feel free to support the draft and as usually, comments are welcome! > > > > > > BR, > > > Daniel > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] > > > Sent: Saturday, October 08, 2016 7:15 PM > > > To: Tobias Guggemos <[email protected]>; Yoav Nir > > > <[email protected]>; Daniel Migault <[email protected]> > > > Subject: New Version Notification for > > > draft-mglt-ipsecme-implicit-iv-01.txt > > > > > > > > > A new version of I-D, draft-mglt-ipsecme-implicit-iv-01.txt > > > has been successfully submitted by Daniel Migault and posted to the > > > IETF > > repository. > > > > > > Name: draft-mglt-ipsecme-implicit-iv > > > Revision: 01 > > > Title: Implicit IV for Counter-based Ciphers in IPsec Document date: > > > 2016-10-08 > > > Group: Individual Submission > > > Pages: 6 > > > URL: > > https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-01 > > .txt > > > Status: > > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > > > Htmlized: > > https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-01 > > > Diff: > > https://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-implicit-iv-01 > > > > > > Abstract: > > > IPsec ESP sends an initialization vector (IV) or nonce in each > > > packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, AES- > > > CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not > > > require an unpredictable nonce. When using such algorithms the > > > packet counter value can be used to generate a nonce, saving 8 octets > > > per packet. This document describes how to do this. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > > > The IETF Secretariat > > > > > > _______________________________________________ > > > IPsec mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
