Re: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-12.txt
Paul Wouters writes: On Mon, 8 Nov 2021, internet-dra...@ietf.org wrote: Filename: draft-ietf-ipsecme-iptfs-12.txt A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-12 Looks good to me other than a typo: s/the they fall/they fall/ (but we can let the RFC editor fix that one without issuing a new draft) Thanks, I've made the update locally to keep track of it as well. Also, Yoav flagged "is comprised of" to me off-list, so I locally changed those to "consists of". There's a subgroup of language experts that really don't like people to use "is comprised of". :) Thanks, Chris. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-12.txt
I've read the diff, and it looks good to me. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Comments on draft-smyslov-ipsecme-ikev2-auth-announce
On Mon, 8 Nov 2021, Tero Kivinen wrote: Does the AuthMethod apply to the algorithms within the certificate as well? The RFC should clarify this. The reason for this notify is that if the peer has multiple key pairs (i.e., private keys) it needs to pick one private key to sign the AUTH payload with. If one of those private keys is using EC and another is using RSA, then without this notification there is no way of knowing which one to pick (except perhaps by prior configuration or by heuristics based on the CERTREQ etc). What will be in the notification then? Since the authenticaion method for both is "RFC 7425 Digital Signatures" as per existing IANA registry for IKEv2 Authentication Methods. We would still need a new registry or we need to identify auth algorithms by their SPKI similar to how we can signature supported hash algorithms. But we would prob end up with seeing lots of duplicate entries with slightly different SPKI prefixes. The RSS-v1.5 vs RSS-PSS is a major pain right now, and implementations using 7425 and specifying RSA-v1.5 SHA1 are a double pain as the RFCs clearly doesn't allow that. We run into frequent interop issues with these. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Comments on draft-smyslov-ipsecme-ikev2-auth-announce
Scott Fluhrer \(sfluhrer\) writes: > I’m glad to see this work; however I see a potentially important > constraint on authentication that the current draft does not appear > to address. > > It allows the peers to specify which signature algorithms they > accept; however if we are talking about certificates, those include > internal signature algorithms, which may be different. One instance > where I expect this to come up is that the root certificate may have > a more conservative algorithm choice (e.g. a hash based signature, > or one with NIST level 5) than the device certificates (which may > have a short expiry time, and so being so conservative might not be > necessary). > > Does the AuthMethod apply to the algorithms within the certificate > as well? The RFC should clarify this. The reason for this notify is that if the peer has multiple key pairs (i.e., private keys) it needs to pick one private key to sign the AUTH payload with. If one of those private keys is using EC and another is using RSA, then without this notification there is no way of knowing which one to pick (except perhaps by prior configuration or by heuristics based on the CERTREQ etc). Also in some cases same private key can be used with multiple hashing methods etc, thus indicating what formats of signature are accepted is also needed. On the other hand the signatures in the certificates are already there, and the peers do not have any way of changing them, thus negotiating what are accepted does not help. Peers can already send as many certificates they want and they can also indicate the CAs they trust using CERTREQs, so that should be enough for peers to get algorithms in the certificates sorted out. I.e., if they have multiple paths from certificate(s) matching their private key they are going to use for signing to the trusted roots trusted by other end, they can send all those paths out. The one who gets all those certificate payloads will then search from them, and from its local cache, or even querying more intermediate certificates from the CA and form a trusted path from the one EE certificate to any trusted root that matches the security policy required for the that end. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Comments on draft-smyslov-ipsecme-ikev2-auth-announce
I’m glad to see this work; however I see a potentially important constraint on authentication that the current draft does not appear to address. It allows the peers to specify which signature algorithms they accept; however if we are talking about certificates, those include internal signature algorithms, which may be different. One instance where I expect this to come up is that the root certificate may have a more conservative algorithm choice (e.g. a hash based signature, or one with NIST level 5) than the device certificates (which may have a short expiry time, and so being so conservative might not be necessary). Does the AuthMethod apply to the algorithms within the certificate as well? The RFC should clarify this. Listing the AlgorithmIdentifier’s for all the signature algorithms we can support seems unnecessarily chatty; would it be more prudent to extend the AuthMethod field to 16 bits (and so we (or IANA) would feel more free to dole them out? And, finally, a typo: it’s P-521, not P-512 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WGLC for draft-ietf-ipsecme-rfc8229bis
This is the start of 2 week WGLC on the draft-ietf-ipsecme-rfc8229bis document, ending 2021-11-26. Please submit your comments to the list, also send a note if you have reviewed the document, so we can see how many people are interested in getting this out. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-12.txt
On Mon, 8 Nov 2021, internet-dra...@ietf.org wrote: Filename: draft-ietf-ipsecme-iptfs-12.txt A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-12 Looks good to me other than a typo: s/the they fall/they fall/ (but we can let the RFC editor fix that one without issuing a new draft) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
On Mon, 8 Nov 2021, mohamed.boucad...@orange.com wrote: Note the text of the draft claims it updates RFC 8598 but doesn't do so via an Updates: statement. [Med] We considered to have an "update" header because we were concerned with some MUSTs in 8598. We finally didn't include the update header because of a comment we received from you prior to publishing the first version of the draft. FWIW, here is the exchange we had at that time: ** Med: I have a question for you: now that we don't depend anymore on INTERNAL_IP*_DNS and given that a client can be supplied with 8598 attributes and that 8598 says the following: == If an INTERNAL_DNS_DOMAIN attribute is included in the CFG_REPLY, the responder MUST also include one or both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the CFG_REPLY. .. the INTERNAL_DNS_DOMAIN attributes in a CFG_REPLY payload form a single list of Split DNS domains that applies to the entire list of INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes. == Should we add an update to our daft to indicate that first "MUST" does not apply and that the domains are associated with **ANY** supplied server? Paul: You cannot update that RFC for that kind of processing. The above really says that it makes no sense to have "internal domains" without providing "internal DNS servers". Note that what I said there was that you should not update the _mechanism_ of how CFG requests/responds are done. You should use the existing mechanism with a new value, but use the same negotation mechanism. So the client sends FOO(x) and the server respones with FOO(y) x can be empty (eg the client has no previous notion or preference for FOO. Or if it has one, it can suggest it. The server takes that value only as a preference of the client, but the server is the one making the ultimate decsion if it returns "x" or "y". So your draft should not say the initiator MUST send a zero size request for FOO. That is changing the mechanism. What I was saying in my last email was that making a protocol update where a server receiving a INTERNAL_IP4_DNS may choose not to return any INTERNAL_IP4_DNS is an update to the protocol that would require the Updates: clause to warn implementers to read this document too, as it updates older RFC text. Also, I think the relaxing of the requirement is actually wrong, as it might cause lack of interop between newer servers and older clients not being able to negotiate working DNS if the new servers no longer serve INTERNAL_IP*_DNS CFG payloads. [Med] Older clients can always ask for INTERNAL_IP6_DNS or INTERNAL_IP4_DNS. We will update the note to make this clearer. They can indeed. So I think you should just stick with the CFG request/response semantics and not talk about omitting INTERNAL_IP*_DNS replies if the client asks for those via CFG. This way, the ENC_DNS* payloads are simply defined as new CFG options, and clients and servers will do the right thing when encountering them. And it requires no Updates: clause because it does not modify the behaviour with respect to INTERNAL_IP*_DNS. You might want to say a client SHOULD prefer ENC_DNS* servers over INTERNAL_IP*_DNS servers. I am also not clear on the real use of negotiating hash algorithms for the digest receiving of the ADD server "identity?", as the document states the authentication happens as per Section 8 of [RFC8310] which lists WebPKI or DANE authentication against the name and these methods do not use this digest. I also do not understand the use of the digest. For authentication, is it not needed as the entire IKEv2 exchange is authenticated. [Med] We added the digest to address one of the comments raised in a previous ipsecme meetings: allow to not rely on PKI for validating the encrypted DNS server certificate but convey the end-entity certificate in IKEv2 itself. Ah, I see. I would probably use some different terminology then, and extend the text talking aboyt "as per Section 8 of [RFC8310]" to clarify that. I'll see about producing some text for you. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
Hi Paul, Please see inline. Cheers, Med > -Message d'origine- > De : IPsec De la part de Paul Wouters > Envoyé : lundi 8 novembre 2021 16:20 > À : Tero Kivinen > Cc : ipsec@ietf.org > Objet : Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > On Mon, 8 Nov 2021, Tero Kivinen wrote: > > > Subject: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > > > This is the start of 2 week WG adoption call for this document, ending > > 2021-11-22. Please send your reply about whether you support adopting > > this document as WG document or not. > > I support the idea of conveying a list of DNS servers that support > encryption. I am not sure if this draft's format and content is the right > way forward. [Med] Thanks. The format can always be updated to reflect the feedback from the WG. > > Note the text of the draft claims it updates RFC 8598 but doesn't do so > via an Updates: statement. [Med] We considered to have an "update" header because we were concerned with some MUSTs in 8598. We finally didn't include the update header because of a comment we received from you prior to publishing the first version of the draft. FWIW, here is the exchange we had at that time: ** Med: I have a question for you: now that we don't depend anymore on INTERNAL_IP*_DNS and given that a client can be supplied with 8598 attributes and that 8598 says the following: == If an INTERNAL_DNS_DOMAIN attribute is included in the CFG_REPLY, the responder MUST also include one or both of the INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the CFG_REPLY. .. the INTERNAL_DNS_DOMAIN attributes in a CFG_REPLY payload form a single list of Split DNS domains that applies to the entire list of INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes. == Should we add an update to our daft to indicate that first "MUST" does not apply and that the domains are associated with **ANY** supplied server? Paul: You cannot update that RFC for that kind of processing. The above really says that it makes no sense to have "internal domains" without providing "internal DNS servers". Also, I think the relaxing of the requirement > is actually wrong, as it might cause lack of interop between newer servers > and older clients not being able to negotiate working DNS if the new > servers no longer serve INTERNAL_IP*_DNS CFG payloads. [Med] Older clients can always ask for INTERNAL_IP6_DNS or INTERNAL_IP4_DNS. We will update the note to make this clearer. > > I am also not clear on the real use of negotiating hash algorithms for the > digest receiving of the ADD server "identity?", as the document states the > authentication happens as per Section 8 of [RFC8310] which lists WebPKI or > DANE authentication against the name and these methods do not use this > digest. I also do not understand the use of the digest. For > authentication, is it not needed as the entire IKEv2 exchange is > authenticated. [Med] We added the digest to address one of the comments raised in a previous ipsecme meetings: allow to not rely on PKI for validating the encrypted DNS server certificate but convey the end-entity certificate in IKEv2 itself. > > Paul > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG adoption call for draft-smyslov-ipsecme-ikev2-auth-announce
On Mon, 8 Nov 2021, Tero Kivinen wrote: draft-smyslov-ipsecme-ikev2-auth-announce This is the start of 2 week WG adoption call for this document, ending 2021-11-22. Please send your reply about whether you support adopting this document as WG document or not. I support working on the idea. I am not sure if this document in its current form, properly conveys the differences between supported, accepted and unsupported, rejected. This is especially tricky in the responder side that does not yet know the ID of the peer and cannot lookup configuration details yet. Also, as we have been merging authentication methods into RFC 7427 digital signature format, it is unclear to me how we can convey some of these parameters using existing IANA registries, since the whole point here was that we didnt need to create and maintain one. Eg if we support or allow EDDSA or some new signature algorithm, we might not have any IANA registry for it, and just stating "we support RFC 7427" does not solve the actual problem. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
On Mon, 8 Nov 2021, Tero Kivinen wrote: Subject: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike This is the start of 2 week WG adoption call for this document, ending 2021-11-22. Please send your reply about whether you support adopting this document as WG document or not. I support the idea of conveying a list of DNS servers that support encryption. I am not sure if this draft's format and content is the right way forward. Note the text of the draft claims it updates RFC 8598 but doesn't do so via an Updates: statement. Also, I think the relaxing of the requirement is actually wrong, as it might cause lack of interop between newer servers and older clients not being able to negotiate working DNS if the new servers no longer serve INTERNAL_IP*_DNS CFG payloads. I am also not clear on the real use of negotiating hash algorithms for the digest receiving of the ADD server "identity?", as the document states the authentication happens as per Section 8 of [RFC8310] which lists WebPKI or DANE authentication against the name and these methods do not use this digest. I also do not understand the use of the digest. For authentication, is it not needed as the entire IKEv2 exchange is authenticated. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPsecME Meeting minutes
Here is IPsecME WG minutes. Thanks to minute takers, for making good minutes and including enough of the discussion, especially for the IPTFS issues. -- IP Security Maintenance and Extensions (IPsecME) WG IETF 112 - Monday November 8th, 2021 12:00-14:00 UTC https://meetings.conf.meetecho.com/ietf112/?group=ipsecme==1 Minutes by Paul Wouters, Donald Eastlake, and Jonathan Hammell. Agenda bashing - no changes. # Agenda - Note Well, technical difficulties and agenda bashing - Chairs (5 min) - Document Status - Chairs (10 min) - Work items - IPTFS Christian Hopps (20 min) - Quantum-resistant IKEv2 and big keys Stefan-Lukas Gazdag and Daniel Herzinger (10 min) - Group Key Management using IKEv2 Valery Smyslov (10 min) - Announcing Supported Authentication Methods in IKEv2 Valery Smyslov (10 min) - AOB + Open Mic (55 min) # WG Status Update Non-adopted documents not listed in the WG Status Report haven't had recent activity, so if editors wish to progress they will need updating. Mohamed Boudacair (on Jabber): Question about draft-btw-add-ipsecme-ike. Tero: Yes. I think that is ready and we should probably start an adoption. # Work items ## IPTFS Christian Hopps, draft-ietf-ipsecme-iptfs WGLC completed in February 2021. Versions -08-11 cover post WGLC comments. Clarified that the reorder window should be small. Recommend use of drop timer instead of reorder window to address packet loss. One last issue from Tero (Oct 31) to resolve. Tero presented on the problem he sees (slides-112-ipsecme-ip-traffic-flow-security-reorderlost-frame-issue-00). Christian: The drop timer is meant to address the delay of inner packets when there is a lost frame. Tero: If IPTFS is fixing reordering, that is a service IPsec wasn't defined for. Christian: Indeed, we are also defining aggregation of packets and fixing the MTU issues with fragmentation, IPTFS is a new technologoy that does new things. Christian: Reorder window is useful in non-constant send-rate scenarios. Drop timer fixes the issue. Ben Kaduk summarized the discussion up to this point. Christian: The drop timer determines the delay. The text should already indicate this. Ben: Others in broader IETF may have thoughts on this. Christian: Using MAYs in Tero's text allows for either behaviour. Should not wait to publish. Ben: Prefer to pick a single solution that we are comfortable with. Lou Berger: Protocols are not built to handle massive reorder windows. Some delay is acceptable. Seems risky to recommend SHOULD in Tero's text. It makes a strong assumption on applications. We don't have the operational experience. Could live with MAY. Valery Smyslov: Processing in reordered flow may cause congestion when the group of inner packets sent. Transport recommendations should be in the draft. Christian: This is still an area of study for the transport area. Tero: Clarified that Valery was recommending documenting the effects of the different scenarios on the flow (will be bursty or delayed) but not on higher protocols. Ben: There are many things we could document, but we might have to be careful about too much. There are many different applications and it will be difficult to give recommendations. Using MAY in both places in the text will allow for this. Tero: Could live with MAY. Recommend renaming the 'drop timer' as 'lost timer'. Should also include a note on the burstiness of inner packets with out-of-order outer packets. Lou: delay and burstiness is documented in the text already. Yoav: Should have a recommendation for the length of the packet lost timer. Deb Cooley (in Jabber): Timer could be proportional to the tunnel rate. Christian: Will publish new draft based on the above agreements/comments. ## Quantum-resistant IKEv2 and Big Keys Stefan-Lukas Gazdag, Daniel Herzinger, slides-112-ipsecme-quantum-resistant-ikev2-and-big-keys-00 Motivation to use of McEliece KEM. Implemented IKE_INTERMEDIATE, Muliple-KE, and Beyond-64KB drafts, using UDP rather than mixed-mode. First slide 100 Mbps. As long as packet loss rate is not too high, around 10 seconds for SA establishment. May be acceptable for high-security scenarios. Second slide is 1 Mbps. The handshake takes much too long. This draft does not seem to be appropriate for this use case. Large key sizes of McEliece could cause memory-exhaustion leading to denial of service attack. Recommend sending large KEs after the AUTH exchange. Valery: Using UDP in unreliable networks is not desirable and is why mixed-mode was introduced. A single classical and single post-quantum exchange may not be desired in all scenarios; Multiple-KE gives much more flexibility. Scott Fluhrer: Questioned whether a 20 second delay was acceptable. Often a single gateway talks to many clients coming in at the same time. How would this proposal be affected? Daniel: Hopefully the
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
Hi Tero, all, I support adoption. FWIW, I'm not aware of any IPR related to this I-D. Cheers, Med > -Message d'origine- > De : IPsec De la part de Tero Kivinen > Envoyé : lundi 8 novembre 2021 15:17 > À : ipsec@ietf.org > Objet : [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > This is the start of 2 week WG adoption call for this document, ending > 2021-11-22. Please send your reply about whether you support adopting this > document as WG document or not. > -- > kivi...@iki.fi > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WGLC for draft-ietf-ipsecme-g-ikev2
This is the start of 2 week WGLC on the draft-ietf-ipsecme-g-ikev2 document, ending 2021-11-26. Please submit your comments to the list, also send a note if you have reviewed the document, so we can see how many people are interested in getting this out. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] The IPSECME WG has placed draft-smyslov-ipsecme-ikev2-auth-announce in state "Call For Adoption By WG Issued"
The IPSECME WG has placed draft-smyslov-ipsecme-ikev2-auth-announce in state Call For Adoption By WG Issued (entered by Tero Kivinen) The document is available at https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-auth-announce/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] The IPSECME WG has placed draft-btw-add-ipsecme-ike in state "Call For Adoption By WG Issued"
The IPSECME WG has placed draft-btw-add-ipsecme-ike in state Call For Adoption By WG Issued (entered by Tero Kivinen) The document is available at https://datatracker.ietf.org/doc/draft-btw-add-ipsecme-ike/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG adoption call for draft-smyslov-ipsecme-ikev2-auth-announce
This is the start of 2 week WG adoption call for this document, ending 2021-11-22. Please send your reply about whether you support adopting this document as WG document or not. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
This is the start of 2 week WG adoption call for this document, ending 2021-11-22. Please send your reply about whether you support adopting this document as WG document or not. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action: draft-ietf-ipsecme-iptfs-12.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for IP Traffic Flow Security Author : Christian Hopps Filename: draft-ietf-ipsecme-iptfs-12.txt Pages : 31 Date: 2021-11-08 Abstract: This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in ESP payload. This new payload type can be used for various purposes such as decreasing encapsulation overhead for small IP packets; however, the focus in this document is to enhance IPsec traffic flow security (IP-TFS) by adding Traffic Flow Confidentiality (TFC) to encrypted IP encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well as non- constant send-rate usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Cost-efficient quantum-resistant DoS protection
> On 1 Nov 2021, at 13:07, Valery Smyslov wrote: > > Hi Michael, > >> Tero Kivinen wrote: Even without surpassing the 64KB limit, this must be a concern. IKEv2's cookie mechanism and puzzles try to increase the cost of the attacker per each connection. Now, an attacker must still accept these costs but can use one connection to trigger several key exchanges, all significantly larger than what we had with DH, making the trade-off way better for them compared to non-pqc IKEv2. >> >>> No it cannot. Attacker can use cookie only once, and will only get one >>> exchange created by each cookie exchange, thus it needs to do puzzles >>> and cookies again for every single attack packet it wants to send. >> >> I wonder if anyone has any stats on how often cookie challenge is used, how >> often puzzles are invoked. > > I've implemented puzzles, but I'm not aware of any other implementation. > > What about cookies - in stress tests they are used very intensively. > But I don't have any real life stats for them. > > Regards, > Valery. I also implemented puzzles. So that makes two of us. Yoav___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
