Re: [IPsec] FW: New Version Notification for draft-suram-dynamic-nat-traversal-00.txt
On Sat, 28 Mar 2015, su...@freescale.com wrote: A new Internet Draft is posted to the working group. The draft addresses a problem where NAT is enabled dynamically (after IPsec SA is created) because of which traffic stops. The draft uses the existing IKEv2 framework (without defining any new payloads) and maintains backward compatibility with older implementations of IKEv2 that does not support this draft. I was not aware this was a problem. So we should really support the use case. I'm not sure yet if this is the right approach. Does this typically happen "once" to a user, or these type of gateways keep switching the NATing on and off? If I'm correct, IKEv2 already requires peers to accept ESPinUDP even without NAT, and so an IKE peer could just enable that, upon which for at least tunnel mode, everything should keep on working. Detection of this based on ESP packets is a little tricky. It requires that the kernel makes a decision based on src/dst IP and existing policy to inform the IKE daemon in userland. Maybe this would be better attached to a liveness probe? There the IKE daemon itself becomes aware of the changed src/dst IP and could enable ESPinUDP. I think that would not even require a protocol change? Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Review for ChaCha20 draft (was: Re: IETF092 draft minutes)
> On Mar 27, 2015, at 9:20 PM, p...@nohats.ca wrote: > - chacha20poly1305 > http://www.ietf.org/proceedings/92/slides/slides-92-ipsecme-2.pdf > > Yoav presenting > > Yaron: does arm have aes acceleration? > Yoav: no. it has something called neon - not in phones but in tablets. has > some advantages > Steve Kent: the "civilian part" keep in mind several industry sectors make > use of FIPS approved algos for liability > purpose. If the motivation is performance, that is not a good argument > anymore. Russ Housley chatted with NIST people > and made optimized miplementation og P-256 so the performance of Curve25519 > is not different enough. Performance is not > a good reason. > Tero: you cannor use curve25519 same for blake ? > Tero: I hate the names A B and C. C for civilian is not a good name. Move UI > out and do UI in separate document > Yoav: I thought we'd have the answer of CRFG by now > ??? from NIST: We received documents and proposal claiming they have to > implement P-256 faster than Curve25519. Has not >been verified. It is just a claim. > PaulH: who will support with review or code: Tero,PaulW, Michael and Valery Hi In the meeting Kathleen asked how long the draft was. With all the algorithm details moved to the CFRG draft, the entire document is six pages, including introduction, IANA and security considerations, references, and the UI suite stuff (that I agree with Tero that should be moved out). The real “meat” of the document is section 2, which spans a little over one page. HTH Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Adopted as a WG work item: Chacha20-Poly1305
Greetings again. At the Dallas meeting, we asked again about adoption of draft-nir-ipsecme-chacha20-poly1305. We got one more promise to review, so with at least five reviewers (Tero Kivinen, Paul Wouters, Jim Knowles, Valery Smyslov, and Michael Richardson), the chairs believe that this represents enough commitment for the WG to take on this work. At the meeting, the WG seemed inclined to not want the material in Section 4 for a variety of reasons. Yoav: please publish draft-ietf-ipsecme-chacha20-poly1305-00, minus Section 4, soon. We will update the charter to indicate this work item, with an expected time to IETF Last Call in May. --Paul Hoffman and Yaron Sheffer ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Milestones changed for ipsecme WG
Changed milestone "IETF Last Call on null authentication", set due date to April 2015 from December 2015. URL: http://datatracker.ietf.org/wg/ipsecme/charter/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Milestones changed for ipsecme WG
Deleted milestone "IETF last call on IKE fragmentation solution". URL: http://datatracker.ietf.org/wg/ipsecme/charter/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Milestones changed for ipsecme WG
Deleted milestone "IETF Last Call on large scale VPN use cases and requirements". URL: http://datatracker.ietf.org/wg/ipsecme/charter/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Milestones changed for ipsecme WG
Deleted milestone "IETF last call on new mandatory-to-implement algorithms". URL: http://datatracker.ietf.org/wg/ipsecme/charter/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] That last bunch of milestone changes
Greetings. I deleted the old "done" milestones from the charter because no one will understand them any more. I also moved the expectation for IETF Last Call for null-auth to April, after Kathleen finishes her re-review. I also put in a request to Kathleen to accept a milestone for Chacha20-Poly1305. --Paul Hoffman ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
