Re: [IPsec] meeting at IETF-95 ?
+1 to having a meeting at IETF 95. Thanks, Tommy > On Jan 12, 2016, at 6:56 AM, Paul Wouters wrote: > > > I hope we are scheduling a meeting for IETF-95. Last time we did not > meet and ended up meeting in the hallway. This time there are more > drafts being suggested and worked on. > > Paul > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-compression-00.txt
> On Jan 11, 2016, at 8:19 AM, Tero Kivinen wrote: > > Yoav Nir writes: >> Second, as I understand it, those battery-powered devices tend to >> use 802.15.4 networks with 127-byte frames. There’s 6LoWPAN to >> provide fragmentation support, but that’s similar to using IKE’s >> fragmentation for the same issue. Can anything be done at all with >> 127-byte frames, that include the (IPv6?) headers, the 8-byte UDP >> header, the 20-byte IKEv2 header in addition to all the payload >> headers? If we need fragmentation anyway, I don’t know if >> compression matters. > > 802.15.4 networks also have 802.15.9, which will provide its own > fragmentation and reassembly for the IKEv2 frames (not including IP or > UDP headers, as those are not used, this is raw IKEv2 frames over raw > 802.15.4 frames). > > In those environments the IKEv2 is used to negotiate link keys between > two devices. The payloads are already quite compacted, i.e. there will > not be several proposals for ciphers, only one, and all extra payloads > are omitted anyways. Tero’s comments seem to confirm the idea that constrained devices will generally be using a small set of proposals, and thus do not need compression. The document referred to in the draft as IPSEC-IOT-REQS, draft-mglt-6lo-diet-esp-requirements-01, recommends essentially one algorithm for the Child SA algorithm (AES-CCM), so it may be safe to assume that IoT devices could converge to a small set of IKE SA algorithms to standardly use. And, while this document does recommend compression for ESP packets, I can see more of an argument being made for compressing ESP traffic (which may be many packets) than for compressing the IKE_SA_INIT packet, which is already a one-time-cost small packet. Valery, do you have specific real-world examples of IKE_SA_INIT packets that are being used by IoT devices that get a benefit from this compression? Without this, it seems that adding compression to IKE would add a fair amount of complexity to optimize a packet that is already fairly inexpensive to send. Thanks, Tommy > -- > kivi...@iki.fi > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] meeting at IETF-95 ?
I hope we are scheduling a meeting for IETF-95. Last time we did not meet and ended up meeting in the hallway. This time there are more drafts being suggested and worked on. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] NIST question concerning IKEv2 and quantum resistance
Hi Panos, thank you for sharing this draft. A couple of quick comments. First, I think that it is better to use a new status Notification to negotiate this feature rather than a Vendor ID payload. It is more in line with the way other IKEv2 extensions are negotiated and it would allow not to waste 16 bytes in the IKE_SA_INIT messages. And second, I'm not comfortable with using fixed algorithms (AES, HMAC_SHA2) and not addressing algorithm agility. Fortunately, your draft says that this might change in future versions. I think it is an important feature ant I hope it'll be addressed. Regards, Valery Smyslov. - Original Message - From: Panos Kampanakis (pkampana) To: Perlner, Ray ; ipsec@ietf.org Cc: Liu, Yi-Kai ; David McGrew (mcgrew) ; Waltermire, David A. ; Frankel, Sheila E. ; Scott Fluhrer (sfluhrer) ; Moody, Dustin Sent: Tuesday, January 12, 2016 8:44 AM Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance Hi Ray, Scott's https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ is the first take of QC resistant IKEv2. It is still in its early stages and has not been adopted as any WG's item yet. Feedback is welcome. Rgs, Panos From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Perlner, Ray Sent: Wednesday, January 06, 2016 3:33 PM To: ipsec@ietf.org Cc: Liu, Yi-Kai ; Moody, Dustin ; Frankel, Sheila E. ; Waltermire, David A. Subject: [IPsec] NIST question concerning IKEv2 and quantum resistance Hi all. NIST is investigating quantum-resistant alternatives to presently standardized public-key algorithms. We are reaching out to the IPSec working group to determine if there are any unique needs associated with trying to add quantum-resistance to IKEv2, which currently only uses variants of the Diffie-Hellman key exchange. We believe a number of the properties of the Diffie-Hellman construction (such as perfect forward secrecy) can be met using generic constructions based on standard cryptographic primitives and security models (such as IND-CCA2 encryption and EUF-CMA signature) as long as key generation times are fast. If IKEv2 can accommodate such generic constructions, there are likely to be many proposals to choose from. However, there are some additional properties of the Diffie-Hellman exchange which may be difficult to duplicate (such as the property that the responder can compute his key exchange message without seeing the initiator's key-exchange message) and it's not as clear to us what the security model for a key exchange replacing DH should be. So in summary, we would like to answers to the following questions: 1) Can IKEv2 can be modified to replace the Diffie-Hellman exchange with a generic construction based on standard encryption, signature, and PRF primitives? 2) If not, what specific security and correctness requirements should we target to meet the need? Thanks, Ray -- ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
