Re: [IPsec] Cost-efficient quantum-resistant DoS protection
> On 10 Nov 2021, at 16:41, Michael Richardson wrote: > > > Yoav Nir wrote: 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. > > Did you ever interop? No. Never got to it. > What is your criteria for enabling them? Do you do this automatically, or is > it an operator configuation to demand them? GUI had three settings: off, cookies, puzzles. In case of cookies or puzzles, they would activate with a certain number of simultaneous IKE negotiations in progress. Because of GUI constraints, that setting had to apply to both IKEv1 and IKEv2 (that was s separate set of radio buttons) Yoav ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Cost-efficient quantum-resistant DoS protection
Hi Michael, > >> 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. > > Did you ever interop? We didn't try, but I think we can do it eventually. > What is your criteria for enabling them? Do you do this automatically, or is > it an operator configuation to demand them? I can only speak for my code. There is a configuration option, that controls the using puzzles. You have the following options: - turn them off - always use them in both IKE_SA_INIT and IKE_AUTH when cookie is requested (which happens if the number of half-open SAs exceeds some configurable threshold) - always use them, but only in IKE_SA_INIT, when cookie is requested - use them only when cookie is requested and some other conditions are met (e.g. you may set a higher threshold for puzzles, than for cookies) You can also set a difficulty of puzzles. It is statically configured. >From my experiments there is a really small interval of complexity when puzzles are useful (so that they do require noticeable efforts from initiators and still are solved within reasonable time, e.g. a few seconds). From my recollection it is between 16-18 bits of complexity. Regards, Valery. > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action: draft-ietf-ipsecme-mib-iptfs-01.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 : Definitions of Managed Objects for IP Traffic Flow Security Authors : Don Fedyk Eric Kinzie Filename: draft-ietf-ipsecme-mib-iptfs-01.txt Pages : 20 Date: 2021-11-11 Abstract: This document describes managed objects for the the management of IP Traffic Flow Security additions to IKEv2 and IPsec. This document provides a read only version of the objects defined in the YANG module for the same purpose. This is an unpublished work in progress. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-mib-iptfs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-mib-iptfs-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-mib-iptfs-01 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
[IPsec] I-D Action: draft-ietf-ipsecme-yang-iptfs-03.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 : A YANG Data Model for IP Traffic Flow Security Authors : Don Fedyk Christian Hopps Filename: draft-ietf-ipsecme-yang-iptfs-03.txt Pages : 28 Date: 2021-11-11 Abstract: This document describes a yang module for the management of IP Traffic Flow Security additions to IKEv2 and IPsec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-yang-iptfs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-yang-iptfs-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-yang-iptfs-03 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] Potential issue with draft-ietf-ipsecme-ikev2-intermediate
On Thu, 11 Nov 2021, Tero Kivinen wrote: My suggestion (as an individual not as a chair) is to add text to security considerations section where we point out that implementations should limit the number of IKE_INTERMEDIATE exchanges they allow to something sensible, like 10 or so. These are exchanges we are doing before authentication so limiting the number of them is something we want to do anyways. I agree. Note, currently our implementation supports a maximum of 1 :) 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 Tommy, All good points. Thanks. Please see inline. Cheers, Med > -Message d'origine- > De : IPsec De la part de Tommy Pauly > Envoyé : jeudi 11 novembre 2021 15:08 > À : Tero Kivinen ; ipsec@ietf.org > Objet : Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > I support adoption of this work. The mechanism of specifying the > authentication domain name and service parameters is sound, and the right > direction. > > I do agree with Paul Wouter’s comments, and I think the parts of the > document that deal with requirements for config requests need work. > Ideally, this doesn’t need to update split-DNS, but instead just reference > the fact that the encrypted resolvers MUST always be preferred when > present. [Med] We will need to decide if we keep this as SHOULD/RECOMMENDED or use a strong language (MUST) as you suggest. > > The text also needs to be careful about not over-mandating behavior. For > example, the text currently says the following: > >If the IPsec connection is a split-tunnel configuration and the >initiator negotiated INTERNAL_DNS_DOMAIN as per [ > RFC8598 > ], the DNS >client MUST resolve the internal names using ENCDNS_IP* DNS servers. > [Med] Agree this should be better worded. The case we had in mind is when INTERNAL_DNS_DOMAIN is negotiated but INTERNAL_*_DNS attributes are not present. In such case, the name are resolved using ENCDNS_IP* servers. There is a MUST in RFC8598 that I do still think is problematic and need to be relaxed in the presence of ENCDNS_IP*. > RFC 8598 has a bit more leeway, explaining that there may be some domains > that are prohibited by local policy from being claimed by the IKE tunnel. > This needs to be maintained. > > For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload that is not >prohibited by local policy, the client MUST use the provided >INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS servers as the only >resolvers for the listed domains and its subdomains, and it MUST NOT >attempt to resolve the provided DNS domains using its external DNS >servers. > > Best, > Tommy > > > On Nov 8, 2021, at 6:17 AM, Tero Kivinen wrote: > > > > 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 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] Potential issue with draft-ietf-ipsecme-ikev2-intermediate
Valery Smyslov writes: > So, the question to the WG is - what should we do with this: > > 1. Re-define calculation of IntAuth to make it constant in size. > This will most probably require another WGLC and will break > interoperablity of existing products. The latter seems not so > important (no product has been released yet), but the former > may delay publication process. > > 2. Leave calculation of IntAuth as is and add some text to the > Security Considerations section that describes potential > problems and makes advise to the responder (e.g. > limit the number of accepted IKE_INTERMEDIATE exchanges). > This will not change bits on the wire and hopefully > will not require another WGLC. My suggestion (as an individual not as a chair) is to add text to security considerations section where we point out that implementations should limit the number of IKE_INTERMEDIATE exchanges they allow to something sensible, like 10 or so. These are exchanges we are doing before authentication so limiting the number of them is something we want to do anyways. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike
I support adoption of this work. The mechanism of specifying the authentication domain name and service parameters is sound, and the right direction. I do agree with Paul Wouter’s comments, and I think the parts of the document that deal with requirements for config requests need work. Ideally, this doesn’t need to update split-DNS, but instead just reference the fact that the encrypted resolvers MUST always be preferred when present. The text also needs to be careful about not over-mandating behavior. For example, the text currently says the following: If the IPsec connection is a split-tunnel configuration and the initiator negotiated INTERNAL_DNS_DOMAIN as per [ RFC8598 ], the DNS client MUST resolve the internal names using ENCDNS_IP* DNS servers. RFC 8598 has a bit more leeway, explaining that there may be some domains that are prohibited by local policy from being claimed by the IKE tunnel. This needs to be maintained. For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload that is not prohibited by local policy, the client MUST use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS servers as the only resolvers for the listed domains and its subdomains, and it MUST NOT attempt to resolve the provided DNS domains using its external DNS servers. Best, Tommy > On Nov 8, 2021, at 6:17 AM, Tero Kivinen wrote: > > 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 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 Orange Restricted > -Message d'origine- > De : Paul Wouters > Envoyé : mercredi 10 novembre 2021 23:24 > À : BOUCADAIR Mohamed INNOV/NET > Cc : Paul Wouters ; ipsec@ietf.org; draft-btw-add- > ipsecme-...@ietf.org; Tero Kivinen > Objet : Re: [IPsec] WG Adoption call for draft-btw-add-ipsecme-ike > > On Wed, 10 Nov 2021, mohamed.boucad...@orange.com wrote: > > 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. > >>> > >>> [Med] We are not saying that in the draft. > >> > >> Section 3.1 states: > >> > >> o Length (2 octets, unsigned integer) - Length of the data in > >>octets. In particular, this field is set to: > >> > >>* 0 if the Configuration payload has types CFG_REQUEST or > >> CFG_ACK. > >> > >> > >> So it says for a CFG_REQUEST the length is 0. > > > > [Med] This is the length of the ENCDNS_IP* attribute. This is used in > requests to indicate that the client is requesting this attribute. > > https://datatracker.ietf.org/doc/html/rfc7296#section-3.15.1 > > The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request > information from its peer. If an attribute in the CFG_REQUEST > Configuration payload is not zero-length, it is taken as a suggestion > for that attribute. The CFG_REPLY Configuration payload MAY return > that value, or a new one. It MAY also add new attributes and not > include some requested ones. Unrecognized or unsupported attributes > MUST be ignored in both requests and responses. > > I see no reason why ENCDNS_IP* should do this differently from all the > other CFG attributes, especially INTERNAL_IP*_DNS. > [Med] Zero-length is allowed for other configuration attributes, e.g., o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute MUST be zero-length and specifies a query to the responder to ^^ reply back with all of the attributes that it supports. It is also allowed for INTERNAL_IP*_DNS: o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the internal network, sometimes called a red node address or private address, and it MAY be a private address on the Internet. In a request message, the address specified is a requested address (or a zero-length address if no specific address is requested). We didn't include a suggested ADN/@ in the proposed ENCDNS_IP* for the sake of simplicity. We are open to relax this if the WG sees so. > > >> But note that I rather that the responder just responds to the > >> received CFG requests with CFG replies it supports and has data for. > >> So if the client asks for INTERNAL_IP4_DNS and ENCDNS_IP4, the > >> responder should return both with values. I also think that in case > >> the encrypted DNS fails, it would be good for the IKEv2 client to > >> have the INTERNAL_IP4_DNS as fallback option. Say if the TLS fails > >> for some reason (incompatible algorithms, expired TLS certificate, > >> DoH server down, etc) > > > > [Med] The current version allows somehow for this as the behavior is > policy-based. However, I understand that you prefer to systematically > return both and leave the client decide. I can live with this as well. > > The policy can be enforced by not returning INTERNAL_IP*_DNS payloads in > the CFG_REPLY. Although if the client did not ask for ENCDNS_IP* and the > server does not return INTERNAL_IP*_DNS, the client would not be able to > get functional DNS. > > I still believe the CFG mechanism is to exchange network topology > information, and not network policy. But you can (ab)use it for that if > you want. The protocol allows it without requiring the change that you > suggest that the sender MUST use 0 length. And this requirement would > force your policy onto everyone else who would be happy to let the client > suggest something (eg 8.8.8.8 or 9.9.9.9) and have the responder maybe > accept those as trustworthy. > > In short, if this document just defines standard CFG REQUEST/REPLY for > ENCDNS_IP* with no additional restrictions, everyone's use case is > supported AND you don't have to Update: RFC 7296 because no existing > behaviour is changed. [Med] I still don't see why you think the document updates RFC 7296. _ Ce message et ses pieces jointes peuvent contenir des informations
