[IPsec] Does I-D of extension of IPComp belongs to IPSec? FW: I-D Action: draft-ls-ipsecme-ipcomp-exclude-transport-layer-00.txt
Shihang(Vincent) writes: > Hi Tero, > We moved our draft of IPComp extension from 6man to IPSecMe because > people told me that IPComp IANA registry is in the IPSec. However > the extension itself is not related to encryption. I wonder if the > IPSecMe is the right place for the draft. It is not, especially as if I remember reight the compressed payload is inside the encrypted payload, thus even if you do not compress the first four octets, they still will be encrypted, thus there is no visibility to them. Where are you trying to use this IPcomp if it is not inside IPsec? On the other hand I do not think current implemetatons of IPsec actually supprot IPcomp mostly because there are some security issues with it, as it may allow different traffic analysis methods to be used which are not available if packets are nott compressed. > I am on site at Brisbane. It would be much appreciated if you have > some time for a quick F2F discussion. > > Thanks, > Hang > > -Original Message- > From: I-D-Announce On Behalf Of > internet-dra...@ietf.org > Sent: 2024年2月28日 20:58 > To: i-d-annou...@ietf.org > Subject: I-D Action: draft-ls-ipsecme-ipcomp-exclude-transport-layer-00.txt > > Internet-Draft draft-ls-ipsecme-ipcomp-exclude-transport-layer-00.txt is now > available. > >Title: IP Payload Compression excluding transport layer >Authors: Cheng Li > Hang Shi > Meng Zhang > Xiaobo Ding >Name:draft-ls-ipsecme-ipcomp-exclude-transport-layer-00.txt >Pages: 8 >Dates: 2024-02-28 > > Abstract: > >IP Payload Compression Protocol (IPComp) is used for compressing the >IP payload in transmission to increase communication performance. >The IPComp is applied to the payload of the IP datagram, starting >with the first octet immediately after the IP header in IPv4, and the >first octet after the excluded IPv6 Extension headers. However, >transport layer information such as source port and destination port >are useful in many network functions in transmission. > >This document defines extensions of IP payload compression protocol >(IPComp) to support compressing the payload excluding the transport >layer information, to enable network functions using transport layer >information (e.g., ECMP) working together with the payload >compression. This document also defines an extension of IPComp to >indicate the payload is not compressed to solve the out-of-order >problems between the compressed and uncompressed packets. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ls-ipsecme-ipcomp-exclude-transport-layer/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ls-ipsecme-ipcomp-exclude-transport-layer-00.html > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] [IANA #1361634] expert review for draft-ietf-ipsecme-multi-sa-performance (ikev2-parameters)
David Dong via RT writes: > Dear Tero Kivinen, Valery Smyslov (cc: ipsecme WG), > > As the designated experts for the IKEv2 Notify Message Types - Error > Types and Status Types registries, can you review the proposed > registrations in draft-ietf-ipsecme-multi-sa-performance-06 for us? > Please see > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-multi-sa-performance/ > > The due date is April 3rd. > > If this is OK, when the IESG approves the document for publication, > we'll make the registration at: > > https://www.iana.org/assignments/ikev2-parameters/ Those two notification message type allocations are ok. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] [IANA #1361470] expert review for draft-ietf-ipsecme-ikev2-auth-announce (ikev2-parameters)
David Dong via RT writes: > Dear Tero Kivinen, Valery Smyslov (cc: ipsecme WG), > > As the designated experts for the IKEv2 Notify Message Types - > Status Types registry, can you review the proposed registration in > draft-ietf-ipsecme-ikev2-auth-announce-06 for us? Please see > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/ > > The due date is April 1st. > > If this is OK, when the IESG approves the document for publication, > we'll make the registration at: > > https://www.iana.org/assignments/ikev2-parameters/ The allocation in draft-ietf-ipsecme-ikev2-auth-announce is ok. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Publication has been requested for draft-ietf-ipsecme-multi-sa-performance-05
Tero Kivinen has requested publication of draft-ietf-ipsecme-multi-sa-performance-05 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-multi-sa-performance/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG Call adoption for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension passed
I just now noticed that I never announced or marked the result of adoptionc alls for these two docments, mostly because they expired, and because that they did not show up in the IPsecME WG document page, so when I searched all documents in Call for Adoption state, they did not show up. Now when Daniel has sent out new versions of those drafts, I can mark them as being adopted. There was quite a lot of non-ipsec people showing up support for these drafts, but I think there was also enough ipsec people saying they are interesed, that we should be able to finish these documents in the WG. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action: draft-ietf-ipsecme-multi-sa-performance-04.txt
internet-dra...@ietf.org writes: > Internet-Draft draft-ietf-ipsecme-multi-sa-performance-04.txt is now > available. It is a work item of the IP Security Maintenance and Extensions > (IPSECME) WG of the IETF. > >Title: IKEv2 support for per-resource Child SAs This seems to cover my comments until section 5, but does not cover the changes for section 5.1, 6, and 9. Is there some issues with those comments? -- In section 5.1 you say that Protocol id MUST contain either 2 for AH and 3 for ESP, but on the RFC7296 says that "If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt." and as this notify is sent with empty SPI field, then the Protocol ID field MUST be 0 also. -- In section 5.1 add text saying that SPI Size MUST be zero. -- In section 5.1 fix s/opague/opaque/ twice. -- In section 6 there is text saying: If the IKEv2 extension defined in this document is negotiated with the peer, an implementation which does not support receiving per-CPU packet trigger messages MAY initiate all its Child SAs immediately upon receiving the (only) packet trigger message it will receive from the IPsec stack. On the other hand there is no negotiation of the this extension. What is this text trying to say? Perhaps simply remove change to say "If an implementation does not support ... it MAY ..." -- Section 9 the correct heading for the IANA registries 2nd column are Notify Messages - Status Types and Notify Messages - Error Types Currently the figure 2 is using status type header and even that does not match iana registry. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPR confirmations for draft-ietf-ipsecme-multi-sa-performance
Are any authors of the draft-ietf-ipsecme-multi-sa-performance (or anybody else) aware of any IPRs related to this draft? Are authors willing to be listed as authors? I will require response from author, and also updated version of the draft based on my review comments, before I will hit publication requested. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Shepherd review of the draft-ietf-ipsecme-multi-sa-performance
In section 1 Introduction: While this could be (partially) mitigated by setting up multiple narrowed Child SAs, for example using Populate From Packet (PFP) as specified in [RFC4301], this IPsec feature is not widely implemented. I think it would be better to give better reason why PFP is not that useful, for example because it could cause way too many Child SAs, and/or way too few Child SAs as the number of Child SAs would be depending on the traffic flow patterns. I.e., if you have all traffic in one TCP/IP session (for example running backup), then you will get only one Child SA for all traffic. On the other hand if you have lots of separate short lived TCP connections (like web browser opening multiple connections to different web servers ect), you would have lots of Child SAs, which would be useless after short while. -- In section 1 change: "as specified in [RFC4301]" with "as specifeid in IPsec Architecture [RFC4301]" -- Add section 1.2 Terminology where you say you use terms Child SA, TSi, TSr, Notification Data, Traffic Selectors, CREATE_CHILD_SA, Configuration Payloads, etc defined in the RFC7296. Expand the list to include all terms used from RFC7296. -- Section 2 typo: s/Implementations/implementations/ -- Section 3 typo: s/multple/multiple/ Also you are using Notification Data (as specified n RFC7296), but then in the end of 1st paragraph you use "notify data payload". Changing those to be consistent would be good. -- In section 4 change twice: in [RFC7296] Section 2.9. with in IKEv2 [RFC7296] Section 2.9. also change As per RFC 7296, with As per IKEv2, (the IKEv2 rfc might not stay 7296 forever :) -- In section 5 say that the Notify Payload format is defined in IKEv2 [RFC7296] section 3.10, and are copied only here to make this document easier to read. -- In section 5.1 you say that Protocol id MUST contain either 2 for AH and 3 for ESP, but on the RFC7296 says that "If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt." and as this notify is sent with empty SPI field, then the Protocol ID field MUST be 0 also. -- In section 5.1 add text saying that SPI Size MUST be zero. -- In section 5.1 fix s/opague/opaque/ twice. -- In section 6 there is text saying: If the IKEv2 extension defined in this document is negotiated with the peer, an implementation which does not support receiving per-CPU packet trigger messages MAY initiate all its Child SAs immediately upon receiving the (only) packet trigger message it will receive from the IPsec stack. On the other hand there is no negotiation of the this extension. What is this text trying to say? Perhaps simply remove change to say "If an implementation does not support ... it MAY ..." -- Section 9 the correct heading for the IANA registries 2nd column are Notify Messages - Status Types and Notify Messages - Error Types Currently the figure 2 is using status type header and even that does not match iana registry. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IETF 119 IPsecME Agenda
Here is the agenda for the next weeks IPsecME WG. Please submit the slides to the datatracker before Sunday. -- IP Security Maintenance and Extensions (IPsecME) WG. IETF 119 - Tuesday, March 19th, 2024 15:30-17:00 https://meetings.conf.meetecho.com/ietf119/?group=ipsecme==1 Agenda - Note Well, technical difficulties and agenda bashing - Chairs (5 min) - Document Status - Chairs (5 min) - Other items - Post-quantum Hybrid Key Exchange with ML-KEM in the IKEv2 draft-kampanakis-ml-kem-ikev2 -- Scott Fluhrer (5 min) - ESP Echo Protocol draft-colitti-ipsecme-esp-ping -- Jen Linkova (15 min) - Shared Use of IPsec Tunnel in a Multi-VPN Environment draft-he-ipsecme-vpn-shared-ipsecsa -- Wei Pan (10 min) - IKEv2 Support for Anti-Replay Status Notification draft-pan-ipsecme-anti-replay-notification -- Wei Pan (10 min) - Using ShangMi in the IKEv2 draft-guo-ipsecme-ikev2-using-shangmi -- Frank (Liang) XIA (10 min) - AOB + Open Mic (30 min) -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Hi, chairs. Request a time slot for a new draft: Using ShangMi in the Internet Key Exchange Protocol Version 2 (IKEv2)
Xialiang\(Frank, IP Security Standard\) writes: > We have a new draft on IKEv2 support for ShangMi cryptographic algorithm > suites: > https://datatracker.ietf.org/doc/draft-guo-ipsecme-ikev2-using-shangmi/. > > The main purpose of this draft is to describe how the Chinese mandatory and > ISO standard ShangMi cryptographic algorithms can be used with IKEv2 to enable > interoperability between vendors in use cases where it needs to be supported. > In addition, it is recommended that related algorithms be added to the IANA > table of IKEv2 Parameters. > > So, we request 10 minutes to present it and collect the comments from the > working group. I think we will have time for short presentation for this in the IPsecME, even if it would then end up on ISE or some other stream. I added it to the end of agenda. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IETF 119 agenda items
If you have anything that you want to be included in the IETF 119 agenda, please send email to the IPsecME WG chairs (ipsecme-cha...@ietf.org) as soon as possible, as I will be making the final agenda tomorrow... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] GDOI and G-IKEv2 payloads
Valery Smyslov writes: > > Ideally, i would even like to see a small section in G-IKEv2 that > > outlines how GDOI extensions can be mapped to G-IKEv2 . If this > > waas all registry entries in RFC8052, then it would IMHO even be a > > great exercise for progressing G-IKEv2 to see if equivalent > > registry entries for G-IKEv2 would be sufficient. And the section > > i am thinking of would for example just be a comparison of > > registry tables. > > I don't think core specification should define how all existing extensions > of an older protocol could be mapped to the current one, but few general > words could be added. G-IKEv2 will have its own IANA registries just like IKEv2 has separate registries compared to the IKEv1. This will mean that none of the old extensions can be used directly for G-IKEv2 as new IANA allocations will be needed, but making new RFC that will define how old G-DOI extension for G-IKEv2 should be quite simple, mostly just doing IANA allocations and using IKEv2 terms and payloads instead of old ones. I do not see any major issues for making an RFC that adds old G-DOI extension to G-IKEv2. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] What's the most reasonable way for the responder to handle the request containing unknown Key Exchange methods
Panwei \(William\) writes: > The handling I suggest is as follows: > > 1) if all KE methods proposed by the initiator are unknown to the > responder, i.e., no KE method is acceptable, then the responder replies > NO_PROPOSAL_CHOSEN, no matter what KE method is used in the KE payload. > > 2) if at least one acceptable KE method is included in the initiator’s > proposals, the responder can select one acceptable KE method, ignore the > unknown KE methods, and perform the next step of KE Payload processing. > >2.1) if the KE method used in the KE payload happens to be the same as > this selected KE method, then the responder normally replies with this > selected KE method and the corresponding KE payload. > >2.2) if the KE method used in the KE payload is different from this > selected KE method, then the responder replies INVALID_KE_PAYLOAD with this > selected KE method, regardless of whether the KE method used in the KE payload > is known or unknown to the responder. This is correct processing. Note, that any unknown KE method cannot be accaptable for the policy, thus they are not allowed by the policy, and if there are any KE methods which are acceptable to policy we use that, and if the KE payload is not using that you send INVALID_KE_PAYLOAD and indicate the KE method you want to use. This processing is same for the known and unknown KE methods, there is no difference there. Of course the initiator will include the exactly same SA payload listing all those unknown KE methods when it retries with the KE method listed in the INVALID_KE_PAYLOAD. > However, others suggest that the responder should terminate the IKE > exchange without reply, when the KE method used in the KE payload is > unknown to the responder, even if there are other acceptable KE > methods proposed in the SA payload. If there is anything in the RFC7296 that would suggest that kind of processing is valid, we need to fix that. The RFC7296 tries to be extendable, thus it tries to ignore unknown values, and process things without them. For example in implementation I was familiar with there were not unknown algorithms, all values for algorithms or methods were valid from IKEv2 point of view, and those values were then matched against policy, but of course policy only allowed values that implementation actually recognized... > Because they feel the unknown KE method in the KE payload means that > the whole packet is an invalid packet, and discarding this packet is > the thing to do. I have no idea where they think RFC7296 says anything like that. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] RFC 4303 ESN and replay protection entanglement
Paul Wouters writes: > In RFC 4303 Section 3.3.3 states: > > Note: If a receiver chooses to not enable anti-replay for an SA, then > the receiver SHOULD NOT negotiate ESN in an SA management protocol. > Use of ESN creates a need for the receiver to manage the anti-replay > window (in order to determine the correct value for the high-order > bits of the ESN, which are employed in the ICV computation), which is > generally contrary to the notion of disabling anti-replay for an SA. This is SHOULD, not a MUST. You do have good reason to do ESN even with anti-replay turned off if your link speeds are that fast, so simply negotiate ESN, and implement your window code in such way that it can keep track of ESN window even when the anti-replay is turned off. I agree that this advise is bad, as ESN is enabled by the sender, but anti-replay is property of the receiver, thus there is no way of sender to know whether other end enables or disables the anti-replay. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed.
Antony Antony writes: > > What we are saying is do this: > > > > T=00:00 Establish IKE SA with 1st Child SA (lifetime 1h for IKE SA, 8h for > > Child SA) > > T=00:01 Establish 2nd Child SA using DH (lifetime 8h) > > T=01:00 Rekey IKE SA > > T=02:00 Rekey IKE SA > > [...] > > T=07:00 Rekey IKE SA > > T=08:00 Rekey all Child SAs without DH > > T=08:01 Rekey IKE SA > > > > At this point all these Child SAs gained PFS because the old IKE SA and > > its KEYMAT are no longer in memory and a compromise now could not > > recalculate the Child SAs anymore. > > Has anyone implemented this yet? This concept sounds intriguing; > however, I am afraid interoperating various combinations of PFS > could become complex to configure as an admin. Often, we end up > creating a new protocol instead of discussing implemenation details. I have not heard any implementation actually implementing that protocol, but on the other hand you could also similate it by setting IKE SA rekey timer low, and having a logic that IKE SA will NOT be rekeyed if there has not been any traffic in it since last rekey. I mean if you have IKE SA which does not have any traffic, there is no point of rekeying it ever, so having such logic would be useful. So I think there is no point of rekeying IKE SA at times T=02:00, T=03:00,..., T=07:00 as there is nothing changing in the state of IKE SA. Then at the time T=08:00 all the Child SAs gets rekeyed, and after that next time there is check for whether IKE SA should be rekeyed, it would notice that it has not been rekeyed for 7 hours which is much longer than the lifetime of 1 hour, and there has been Create Child SA exchanges on IKE SA, thus there is point to rekey it. The perceived value of the different IPsec implementations is what kind of implementation details they pick to when implementing certain things. We do give quite a lot of good advice what should be done to get good implementation in IPsec RFCs, but there is still lots of implementations who do to even implement them and then complain that the performance is bad. In addition to those listed there are even more things you can do depending on your hardware, and that is what makes some implementations better than others. Listing those in the RFC might not help, as those kind of implementation tricks only works on certain architectures or hardwares (i.e., they are not general purpose tricks). For me, it seems lots of the discussion we have here are already something that we solved twenty years ago in our implementations (sometimes only for some specific clients as they had different requirements and/or different hardware) without modifying the base protocol. I always prefer if we can solve the issue without protocol changes, by just making the implementation better... > I herd this idea before, a few times at IETF, and wonder if CFRG > would agree what is written here. It might worth clarifing with > crypto people may be write it down. That depends which definition of PFS is used. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed.
Pierre Pfister (ppfister) writes: > > Sending 144 small encrypted packets, and receiving 144 small encrypter > > packets should not take lots of CPU power. The CREATE_CHILD_SA does > > NOT need to do any Diffie-Hellman, and there is no public key crypto > > on them, so it is just encrypting those packets, sending them out and > > getting responses back. The only thing why it might take long is that > > if you do not implement SET_WINDOW_SIZE. > > AFAIK, per CHILD_SA DH is needed when PFS is enabled. If you are considering all of those Child SAs to be one real SA, which is just split to separate Child SAs because of the multiple cores, then I think you should only do one PFS for them. Of course if you assume someone can hack into only one of the CPUs and can't access other cpus then there might be need to do separate Diffie-Hellman for each of the cpus, but then subspaces draft does not fullfill that requirement either, thus you need to do separate Diffie-Hellman for each of them also. Instead of just having single flag for PFS, you should have better control for when to do Diffie-Hellman for Child SAs than just yes/no. > > All my test results are from more than 10 years back, and we did run > > them mostly on single CPU machines, but I do not think modern CPUs are > > that much more slower than those ones (and I do not remember exact > > results from that far back). > > I don’t think SET_WINDOW_SIZE would really help reducing the overall time > when it gets to scaling up to 1 peers, since the CPU will remain mostly > busy processing and sending packets all the time. SET_WINDOW_SIZE will have huge difference in the overall time to set up the SAs. I mean if setting up one SA takes less than millisecond vs tens or hundreds of millisecods, there is ten or hundered times performance penalty for not using it. Window time DOES NOT help when setting up one SA for each 1 peers, but it helps a lot when setting up 100 SAs for 100 peers. You do not need subspaces if you only have one SA for each peer. To implement subspaces with multiple SAs, you will need create multiple Child SAs with each peer, and there window size will help a lot during the startup phase. > That being said, I agree SET_WINDOW_SIZE is a desirable feature, > unfortunately not available in Strongswan. So that should be first target to do, instead of trying to add new protocol features. I mean it is no suprise you are getting bad performance if you do not even implement the basic features of IKEv2. Yes, the RFC7296 do say that "The following are features that can be omitted in a minimal implementation", and that list includes things like window sizes greater than one, EAP authentication, NAT-traverseal, establishing multiple Child SA with single IKE SA, rekeying SAs... > The other issue I mentioned above is even more of a problem, and > it’s about how many keys can be stored in the crypto hardware. Of > course that number depends on how much money you are willing to > spend on the hardware, but in the high-end boxes I work on, that > number doesn’t go beyond a few thousands. Dividing by 64+ the number > of tunnels we can operate in hardware (vs slow-path in software) is > not an option. So what kind of limits the current hardware have? And do you think those hardwares are able to implement subspaces in such way that they share keys? I mean sequence number generation on the AEAD ciphers are usually considered to be inside the crypto boundary, so to implement different counters for each different core, might still require multiple hardware keys to be installed if each key includes sequence number also. Can you give some real world examples which kind of limits there are on specific hardware? -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed.
Michael Pfeiffer writes:
> 1) The main effort for "full" child SAs is not only setting them up,
> but to maintain them (rekeying, monitoring, sending heartbeats and
> the like). In our experience, this becomes especially bad when
> partial failures are possible, i.e., a strict subset of the child
> SAs may fail. This could happen due to, e.g., on-demand child SA
> creation, or if NAT-T maps the child SAs to different UDP ports and
> a misconfigured firewall drops some of the flows.
NAT-T is a property of the IKE SA, and all Child SAs are going to use
the same UDP source and destination ports, so only way child SAs might
be using wrong port is if the IKE SA port numbers are not properly
propagated to all Child SAs, but that is implementation bug and should
not happen.
Also I do not understand what you mean by "sending heartbeats"? If you
are talking about the NAT Keepalives, they are again property of the
IKE SA, thus all child SAs do share keepalives, and there is only ever
need to send them if every single Child SA has been silent over NAT
keepalive period. If using default NAT keepalive period of 20 seconds
that means that IKE daemon needs to poll all cpus every 20 seconds to
see if there are any childs for each of their IKE SAs that has not
sent any packets since last poll. This operation depends mostly on the
number of IKE SAs, and immediately when it finds one cpu that has sent
out any packets on any of the Child SAs associated to the IKE SA, it
can bail out, and ignore sending of keepalive.
Note, that recipient of NAT keepalive does not matter, as you MUST NOT
do anything based on them. Also this only affects devices which are
BEHIND nat, i.e., most bigger security gateways will not be behind
NAT, while the clients connecting to them are behind NAT.
Rekeying, monitoring etc is something you need to do anyway, I do not
think there is that big difference there. It might even be simplier
with separate Child SAs as you do can do byte counting on the CPU that
contains the Child SA, with subspaces you need to collect summary of
number of bytes transmitted over all of the subspaces while counting
whether the Child SA needs to be rekeyed or not.
> 2) Regarding the hardware discussion, the main problem is not the
> interconnections between large sites, e.g., data centers
> ("network-to-network", as Ben calls them). Those are usually large
> devices with plenty of computing power on both sides and
> high-bandwidth links in between, so multiple child SAs may be used
> there.
>
> The in our opinion pathological cases are the SAs between large
> sites and very small sites (low-power gateways for small offices,
> notebooks, or mobile phones), so a typical access scenario. In this
> case, we have two options:
>
> a) Using a "classical" single child SA to the small site. But on the
> large gateway, we usually cannot control on which cores the
> plaintext traffic flows for that SA are received, as they are chosen
> by RSS. This means we either need to sync sequence counters between
> cores, or move the flows to the single core responsible for the SA.
> Both have a significant negative impact on the overall performance
> of the gateway.
On the other hand if the other end is "small site" by definition then
the bandwidth needed is most likely also smaller, i.e., if the other
end can't cope with creating multiple Child SAs because it is so
small, then having only one core taking care of traffic to that site
is not an issue. The one core can easily take care of that, if the
small site is able to process that data on its one core...
I do assume you already have a efficient way of routing traffic inside
your machine to correct core having Child SA for that traffic. You
most likely want to keep same flows on same Child SAs anyways.
> b) Using one child SAs for every core of the large gateway. This
> means we do not need to sync sequence numbers or move flows anymore,
> but have shifted the problem to the small device. There, we now need
> to set up, rekey, and monitor, say 64 SAs for the cores. Depending
> on the scenario, this number may easily be multiplied by 4-8 for QoS
> and doubled again for redundancy or multipathing. The problem
> becomes especially bad for battery-powered devices such as notebooks
> or mobile phones.
Are you assuming this small site is connected to just one large site,
or is this going to be full mesh thing? If small site is only
connected to one site, then having the small site processing few
hundreds of SAs should not be an issue. At least old Pentium PCs we
run tests on 20 years ago could do it, so I assume modern systems can
also do it. The number of Child SAs were never really an issue, the
issue was that they could not do the encryption on the line speeds,
and that was was slowing them down.
Notebooks, and mobile phones are usually not connected with gigabit
links, and are not able to encrypt/decrypt data on that speeds
anyways. In those cases the amount traffic is the important
[IPsec] Why ipsecme-anti-replay-subspaces is needed.
Pierre Pfister \(ppfister\) writes: > "Creating 144 IPsec SA should take less than tenth of a second. > IKEv2 have windowing mode. With really big systems, creating more > SAs is not an issue." > > We unfortunately cannot afford to throw more cores at every scaling > issue that we have. IPsec hardware is pretty much limited today by > how many keys you can store. And IKEv2 by how many SAs you must > negotiate (Big concern when PFS is enabled). Sending 144 small encrypted packets, and receiving 144 small encrypter packets should not take lots of CPU power. The CREATE_CHILD_SA does NOT need to do any Diffie-Hellman, and there is no public key crypto on them, so it is just encrypting those packets, sending them out and getting responses back. The only thing why it might take long is that if you do not implement SET_WINDOW_SIZE. I.e., if you used window size lets say 64, that means that you can send 64 CREATE_CHILD_SA requests out, meaning symmetric encrypting few kB worth of data, so that should not take more than few milliseconds. Then you need to wait for the responses, and if the server is far away, you might need to wait for lets say 100ms for responses, and then decrypting and processing responses takes again few milliseconds. Then you repeat this 3 times, and you should be able to create those 144 SAs in about 300-500 ms, using less than 100 ms of CPU time. All my test results are from more than 10 years back, and we did run them mostly on single CPU machines, but I do not think modern CPUs are that much more slower than those ones (and I do not remember exact results from that far back). > We need to establish peerings with 10k peers. All our control-plane > daemons, routing protocols, IKEv2, must run on one or two cores to > leave room for the actual data-plane features. Create IKE SA is much more expensive than create Child SAs, thus create 1 IKE SAs will take quite a lot of time and CPU than doing the additional Child SAs for them. How fast can you create those 1 IKE SA in your system now? How long does it take to create 100 Child SAs using window size of 64 on one IKE SA? > What exactly did you mean by "big systems" ? The big systems we used for testing are most likely slower than the modern phones, so there is no point of me trying to remember what your big systems are. I would assume you have some systems you can run some tests on, so can you (or someone else, Valery?) do those and come back with numbers so we know what are the numbers on current hardware. The important thing is to make sure you set the IKE window size to large enough value, i.e., something like 32 or 64, otherwise your performance is going to be really slow. > To give a more concrete example: > > One of the reasons for IKEv2 design was to support multiple traffic > selectors per SA (See point 9 in > https://www.rfc-editor.org/rfc/rfc7296#appendix-A). In IKEv1, the > design was also to throw more SAs at the problem. Someone who needed > multiple different traffic selectors would create multiple SAs. We > are repeating the same historical mistake now but with cores instead > of traffic selectors. Actually the point 9 is completely different. IKEv1 shared the ID payload for the traffic selectors, thus it was hard to express the policies people wanted with the very limited structure of the ID payload (i.e., either exactly one IP, IP subnet or IP range was possible, no protocol or port). In IKEv1 you could not throw more SAs on the problem, as people had different understanding whether the new SA will replace or not replace the previous SA. On the other hand there was a way to create multiple SAs with one Quick Mode exchange, with exactly same "traffic selectors" but different algorithms and SPIs, but I do not know if anybody implemented this feature ever (even my implementation did not implement that if I remember right). The reason for point 9 is that we wanted to separate the ID payload and traffic selector payload, so we can have things like protocols and ports there too, on the other hand we simplified it by removing everything else than address ranges. The reason it support list of ranges is because the decorrelated policy from RFC4301 will quite often generate multiple ranges for the same policy rule, because of how the decorrelation works, i.e., it punches holes on the rules by removing IP address ranges covered by higher priority rules. We did not think this completely through, as we should have included protocol ranges too, as now you can't easily express everything else except TCP port 25 using traffic selectors. > The multi-sa draft is not bad and surely solves some of the > problems. However, it also emphasizes that we're back to the same > issues as IKEv1 trying to solve our modern performance problems by > adding more SAs. I do not think we are going anywhere to the direction of IKEv1. IKEv1 implementations did not try to solve issues by creating multiple SAs, as this would have
[IPsec] WG Adoption call for draft-mglt-ipsecme-ikev2-diet-esp-extension
This is two week adoption call for draft-mglt-ipsecme-ikev2-diet-esp-extension. If you support adopting this document as a working group document for IPsecME to work on, and then at some point publish this as an RFC, send comments to this list. This adoption call ends 2023-12-13. Note, that I do want to see people saying that they think this document is worth of working on, and that they plan to review and comment on it. If I only get one or two people (including authors :-) to say they support this work, then there is no point of work on this in WG. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG Adoption call for draft-mglt-ipsecme-diet-esp
This is two week adoption call for draft-mglt-ipsecme-diet-esp. If you support adopting this document as a working group document for IPsecME to work on, and then at some point publish this as an RFC, send comments to this list. This adoption call ends 2023-12-13. Note, that I do want to see people saying that they think this document is worth of working on, and that they plan to review and comment on it. If I only get one or two people (including authors :-) to say they support this work, then there is no point of work on this in WG. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt
This is two week adoption call for draft-smyslov-ipsecme-ikev2-qr-alt. If you support adopting this document as a working group document for IPsecME to work on, and then at some point publish this as an RFC, send comments to this list. This adoption call ends 2023-12-13. Note, that I do want to see people saying that they think this document is worth of working on, and that they plan to review and comment on it. If I only get one or two people (including authors :-) to say they support this work, then there is no point of work on this in WG. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance passed
Paul Wouters writes: > On Mon, 20 Nov 2023, Tero Kivinen wrote: > > > After some probing in the Prague, we managed to get good discussion > > and reviews on this draft, and I think the consensus on the list was > > that it should be ready to go forward. > > Note that we are still discussing on the list with Valery on a few > items, so I do expect to do at least one more draft version. At > which point you can either repeat a WGLC or send it to Roman. Thats ok, I can most likely will not be able to start my writeup before that anyways, and there might be some things that needs changeing after my review anyways. > > The adoption calls are still waiting for our security AD to respond, > > but I will start the ones listed on our charter when I get back > > Finland on Wednesday. > > These are about other drafts not mentioned in the subject line I guess? > Note Roman is mostly the last two weeks of November (American Thanksgiving > and all) so his responses might be a bit slower. I wam talking about draft-smyslov-ipsecme-ikev2-qr-alt, draft-mglt-ipsecme-diet-esp, draft-mglt-ipsecme-ikev2-diet-esp-extension. Last two are mentioned in the charter, and the first is continuation of our post quantum work, so I will start WG adoption calls after I get back to Finland. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Interesting attacks on PKCS#v1.5 in IKE
Paul Wouters writes: > What I take from this: > > - Maybe look at a new EAP method to prevent AUTH payload from the >server to be send before client is authenticated. When we were designing IKEv2 we had long discussion about who should authenticate first. If the initiator authenticates first, that allows attackers to find out identity of the client / remote users, which might be more valuable than the identity of the server. The identity of the server is quiet often already known based on the IP-address. Making resopnder to authenticate first will allow attackers to do scanning of identities on the network, i.e., they can connect to hosts and do active connection and get the authenticated identity of the server. > - Implementations MUST reject weak PSKs that are easy to detect. To that to be MUST, it would require some specific methods to tell how you can detect weak PSKs. We already have: Note that it is a common but typically insecure practice to have a shared key derived solely from a user-chosen password without incorporating another source of randomness. This is typically insecure because user-chosen passwords are unlikely to have sufficient unpredictability to resist dictionary attacks and these attacks are not prevented in this authentication method. On the other perhaps we should think of moving Secure Password Framework for IKev2 (RFC6467) and ONE of the associated password authentication methods to standard track, and try to get people to implement them. If I remember right CFRG has now selected one augmented and one non-augmented PAKE, so perhaps we could simply say use them, but I have not checked whether we have either one of them defined for Secure Password Framwork (RFC6567) uses. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Agenda for IETF 118
Pierre Pfister (ppfister) writes: > Would it make sense to swap Steffen’s presentation with mine ? (If that’s ok > with you Steffen ?). Sure, I will swap them. > A lot of what’s in their draft covers the problem statements to the sequence > number subspaces proposal, and would be useful background information before > our presentation. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Agenda for IETF 118
Ana Minaburo writes: > From my point of view you need to work more on your draft to be aligned with > SCHC. This work needs a better understanding of the SCHC header compression. > And it will be required to be worked in parallel in both SCHC and IPsecME WG. This is just adoption call for the IPsecME WG, where we check out if there is enough people interested to work on this problem. After we have adopted the document, then the real work on the document starts, so there is plenty of time to align it with SCHC. We already have in the IPsecME charter a following item: A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. And this work fits to that, so we just need to see there is enough people interested working on this to adopt. > On Mon, Oct 30, 2023 at 12:10 PM Daniel Migault wrote: > > Just to let you know that we will have a call for adoption for diet-esp, > that is IPsec/ESP compression with SCHC.I will be in Prague so we can also > discuss this face to face. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Slides for the presentations for IETF 118
Submit the slides for the presentations for IETF 118 agenda items before Friday 3rd. If no slides are submitted by then, I assume we can free the agenda slot, and get more time for other presentations. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Agenda for IETF 118
IP Security Maintenance and Extensions (IPsecME) WG. IETF 118 - Thursday November 9th, 2023 13:00-14:30 CET https://meetings.conf.meetecho.com/ietf118/?group=ipsecme==1 Agenda - Note Well, technical difficulties and agenda bashing - Chairs (5 min) - Document Status - Chairs (5 min) - Adoption calls (5 min) - draft-liu-ipsecme-ikev2-mtu-dect - draft-mglt-ipsecme-dscp-np - draft-mglt-ipsecme-diet-esp - draft-mglt-ipsecme-ikev2-diet-esp-extension - draft-smyslov-ipsecme-ikev2-cookie-revised - Other items - Issues with DH with IKEv2 and rekeys (15 min) Paul Wouters - QR alt update (10 min) Valery Smyslov - Anti-replay sequence number subspaces (10 min) Pierre Pfister - Update of multiple sequence counters (10 min) Steffen Klassert - Beet mode (10 min) Antony Antony - Esp trailer adjustment (5 min) Wei Pan - Delete info (5 min) Paul Waters - RISAV update (5 min) Yangfei Guo - AOB + Open Mic (5 min) -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AD Review of draft-ietf-ipsecme-ikev2-auth-announce-04
Valery Smyslov writes: > > ** Section 3.2 > > > > If more authentication methods are defined in future, the > > corresponding documents must describe the semantics of the > > announcements for these methods. > > > > -- Should this be a s/must/MUST? > > With my understanding of using BCP14 language, these keywords are > usually concerned with protocols behavior. In this case the "must" > is concerned with human (document authors) behavior :-) > > That said, I understand that this may be interpreted differently, so > if you think "MUST" is more appropriate here than "must", I'll be > happy to make the change. I think lowercase must is correct, as this is not protocol issue. I have also had a customers to come to me asking me which specific lines of code implement every single MUST/SHOULD etc. I already had difficulties to explaining which lines of code implement some of the MUST NOTs, but it would be even harder to explain which line of code implements the MUST given to future spec writers... Of course, we could require that in the future all specs are written by AI, and that AI MUST follow all MUST rules set in previous RFCs :-) Ah, I just realized that does not work, as there is no way to give the lines of code that implement that requirement in the AI... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Call for IETF 118 agenda items
I have already received few requests for the agenda items for the IETF 118 IPsecME WG meeting, but if you want to have items on the agenda on the IETF 118, send them to ipsecme-cha...@ietf.org by the end of this week. I will finalize the agenda during the weekend. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance
This will start three week working group laste call for draft-ietf-ipsecme-multi-sa-performance. The working group last call will end at 2023-11-15. Please review the document and send comments to the list if you think it is ready for publication. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Publication has been requested for draft-ietf-ipsecme-ikev2-auth-announce-04
Tero Kivinen has requested publication of draft-ietf-ipsecme-ikev2-auth-announce-04 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Shepherd review of the draft-ietf-ipsecme-ikev2-auth-announce
I would need author to reply this email and express whether there is any IPRs related to this draft known by the authors. -- In section 3.1 the draft says: Instead, the initiator MAY either link the Announcements to the CAs received in the IKE_SA_INIT response, or MAY ignore the SUPPORTED_AUTH_METHODS notification entirely. but instead of ignoring the SUPPORTED_AUTH_METHODS notification entirely, it could simply ignore the cert linking. If it ignores the whole SUPPORTED_AUTH_METHODS it might pick completely unusable method, so instead it should use that to pick suitable methods, even when it can't link them to specific trust anchors. -- In section 3.2 the draft says: The meaning of the remaining octets of the blob, if any, depends on the authentication method and is defined below. I think it would be simply bettter to say: The meaning of the remaining octets of the blob, if any, depends on the authentication method. as in the future some of those authentication methods might be defined in other documents and not below... -- As this document adds two new variations of the basic IKEv2 IKE_SA_INIT / (IKE_INTERMEDIATE) / IKE_AUTH, it would be really good to have IKEv2 RFC 7296 Appendix C style exchange summaries. Please add those. -- I-D nits complain : == Outdated reference: A later version (-09) exists of draft-ounsworth-pq-composite-sigs-08 so fix that also at the same time. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] wrong and missing IANA ikev2/esp reference ?
Paul Wouters writes: >In addition, IANA has added this RFC as a reference to both the ESP >Reference and IKEv2 Reference columns for ENCR_AES_GCM entries, while >keeping the existing references there. Also, IANA has added this RFC >as a reference to the ESP Reference column for ENCR_CAMELLIA_CCM >entries, while keeping the existing reference there. > > The text describes doing the wrong thing, but implies this was > already done by IANA? But that might just be the writing style > (blame me) and we just told them to do the wrong thing. The iana considerations sections are written based on the final result, i.e., where all the changes to the registries has already been done by IANA. For example RFC7296 IANA considerations says: IANA has updated all references to RFC 5996 to point to this document. etc... And the actual reason why the references for AES-GCM and CAMELLIA-CCM was added was because they were renamed: This document renames some of the names in the "Transform Type 1 - Encryption Algorithm Transform IDs" registry of the "Internet Key Exchange Version 2 (IKEv2) Parameters". All the other names have ENCR_ prefix except 3, and all other entries use names in the format of uppercase words separated with underscores except 6. This document changes those names to match others. I think we actually planned doing this just by asking IANA to modify the registry, but IANA requested that we should instead put it in some RFC so there will be history explaining the situation, thus we added IANA considerations to the RFC8247 to do the renaming. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] wrong and missing IANA ikev2/esp reference ?
Paul Wouters writes: > See > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5 > > I noticed that the IKEv2 column for AES_GCM variants mentions RFC > 8247. This should be RFC 8221. And for AES_CCM, the ESP and IKEv2 > columns are missing the RFC 8247/8221 entries entirely. No. IKEv2 column should still be for IKEv2 use of the AES_GCM, thus RFC8247 is more appropriate than RFC8221. But the reason RFC8247 is listed for ESP and IKEv2 reference columns for the AES-GCM and CAMELLIA is because the RFC8247 changed the name of those algorithms: +---+--+ | Old name | New name | +---+--+ | AES-GCM with a 8 octet ICV| ENCR_AES_GCM_8 | | AES-GCM with a 12 octet ICV | ENCR_AES_GCM_12 | | AES-GCM with a 16 octet ICV | ENCR_AES_GCM_16 | | ENCR_CAMELLIA_CCM with an 8-octet ICV | ENCR_CAMELLIA_CCM_8 | | ENCR_CAMELLIA_CCM with a 12-octet ICV | ENCR_CAMELLIA_CCM_12 | | ENCR_CAMELLIA_CCM with a 16-octet ICV | ENCR_CAMELLIA_CCM_16 | +---+--+ As the AES_CCM was not renamed there is no reference to the RFC8247 in its references. Note, that the Note in the beginning of the registry do provide pointers to the RFC8221 and RFC8247 for requirement levels: Note To find out requirement levels for encryption algorithms for ESP, see [RFC8221]. For IKEv2, see [RFC8247]. and there is no need to add RFC8221 or RFC8247 to any algorithms just to get that reference... > If someone would like to confirm these errors, I can see about what the > process is to fix these :) There is no errors. And the process to fix them is to contact IANA (which will contact designated experts), or the designated experts directly :-) -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-mglt-ipsecme-ts-dscp
Daniel Migault writes:
> Thanks for the comments, this matches how we envisioned to update the draft,
> except that we envisioned the responder sends a N(DSCP) and that we also
> indicated the support of the N(DSCP). I think you recommend not to have these
> two notifications, which could work for us.
Yes, it would be also ok to have the responder to send the N(DSCP) to
indicate it will also be using this SA for those DSCP values. On the
other hand it is also possible that the responder does not support
this new notification and the initiator has to be able to cope with
situation still, thus it could be enough if we say that
implementations supporting this draft SHOULD send matching DSCP values
sent by the initiator to the SA created in other direction.
Or we can simply say that this N(DSCP) is sent by either end along
with the SA payload and it indicates that sender of that notification
tries to put packets with those DSCP values to the SA negotiated using
that SA payload.
I.e., the N(DSCP) values does not need to match, both ends will simply
indicate which DSCP values they are putting to that SPI indicated
inside the SA payload:
Initiator Responder
---
HDR, SK {SA, Ni, KEi, N(DSCP, 1, 4)} -->
<-- HDR, SK {SA, Nr, KEr, N(DSCP, 1, 4)}
or responder could also answer:
<-- HDR, SK {SA, Nr, KEr, N(DSCP, 1)}
if it is not using DSCP value 4 at all, but it could also use:
<-- HDR, SK {SA, Nr, KEr, N(DSCP, 8)}
if its policy says that initiators DSCP values 1 and 4, are not used
in its network, but DSCP value 8 has similar meaning, and thats why it
is using that instead.
So the N(DSCP) notification will tell that the sender of the
notification will put those DSCP values to the SA indicated by the SPI
inside the SA payload. There is no agreement, simply a statement from
the sender of that notify.
> If the SA used for those DSCP values is deleted then SA which do not
> list DSCP values will be used (i.e., the fall back SA). If there is no
> SA that does not list DSCP values, then the RFC4301 does not really
> specify which SA is used, but I would assume it could use any SA.
>
> I think we need to clarify this. 4301 is not crystal clear and I
> thought no SA would be selected, but I think that is correct any SA
> can be selected.
Yes. I agree that 4301 is not exactly clear about that, but we can say
it in this draft.
> I.e., the DSCP status notification indicates which DSCP values you are
> going to put in that SA, and the receiver is recommended to put same
> DSCP values to this same SA.
>
> This does not give the possibility to negotiate the DSCP values, but
> I agree that sounds reasonable and easier.
We do not really need negotiation (i.e., where both end propose things
and after few round trips they negotiate common situation), it is
enough to have agreement (i.e., both ends knows what other end is
going to do). If we say that responder can also use the N(DSCP)
notification along its SA payload then we get this agreement, i.e.,
both ends will know which SAs are used for which DSCP values.
> Note, that if the recipient does not support this feature, it will
> simply ignore that status notification and put pick suitable SAs for
> each DSCP values based on its own policy.
>
> This means the initiator does not know if the responder supports the DSCP
> partition.
If the other end claims to support RFC4301 it will support putting
DSCP partition :-)
On the other hand initiator does not know whether responder's policy
will consider DSCP values important enough to cause them to use
separate SAs, but initiator knows that it can create multiple
overlapping SAs and use them to send different DSCP values over them,
and responder will process them correctly.
The question is what can the initiator do if the responder policy does
not put different DSCP values to different SAs? There is nothing it
can do to fix the situation, the only thing it can really do is to
tear down the SA and refuse to talk to that peer, but I do not think
that is something we want to do.
In IKEv1 we had lots of cases where policy must be exactly same in
both ends, and if there was any difference in the policy (for example
other end had SA life time of 3600 seconds, and other end had 3599
seconds), then SA creation failed, and adminstrators needed to go and
update the policy to match.
In IKEv2 we removed lots of those cases, i.e., we do not even try to
enforce same policy, we simply say that sender will enforce the policy
it wants, and it can announce its policy to the other end and other
end will have to work with that...
> One inconvenience I can see is that if the initiator does not check
> he will not be able to notice the responder does not support it and
> so two SAs may not be so necessary.,
Re: [IPsec] draft-mglt-ipsecme-ts-dscp
Daniel Migault writes:
> I am coming back to one comment that has been made during the
> presentation that DSCP values do not necessarily be associated with
> a pair of SA.
>
> We want to organise tunnels where DSCP values are partitioned
> between a subset of SAs. More specifically suppose that we have g1 =
> (DSCP_a, DSCP_b), g2 = (DSCP_c) and g3 = (remaining DSCP) that are
> spread over 3 distinct pairs of SAs (SA1, SA2, and SA3).
>
> As long as peer A and peer B have agreed on 3 distinct SAs, and on a
> way to group the DSCP code point, the repartition could be left to
> each peer. For example, peer A may steer traffic g1 to SA1, g2, to
> SA2 and g3 to SA3, while peer B may steer g1 to SA3, g2 to SA2 and
> g3 to SA1. The tunnel may be split over a distinct pair of SAs.
The reason we want to provide each of those groups separate SA is
because we have some information from somewhere that something in the
network will process the outer DSCP values differently, and that will
cause issues for the replay window.
Note, that RFC4301 "4.4.1.2. Structure of an SPD Entry", already
specifies that you can either bypass DSCP value from inner to outer IP
header or you can map inner DSCP value using a map stored in the SPD
to DSCP values for outer IP header.
In most cases you will have external knowledge that someone will
process your specific DSCP values differently on the outer IP header,
so you should most likely use that DSCP mapping to map all those
groups to specific outer DSCP values.
So now the question really is which DSCP values you want to tell the
other peer? The outer IP header values are only ones that affect the
processing of the packet over the internet, so those would be more
logical ones. On the other hand that would require you to agree with
peers a same mapping of the inner to outer values.
If we agree on the inner DSCP values, but map them differently that
does not actually matter as long as we never bypass some DSCP values
while mapping others, as every packet in the tunnel will have same
outer DSCP value thus will receive same processing in the internet.
So that means we most likely should agree on the inner DSCP values,
and assume that both peers do have common understanding of those
values.
If you want to keep the group so that it uses the same SA pair, then
if both peers already have common understanding of the DSCP groups,
this is not an really an issue, as we can simply wait for the
initiator to send first packet and see which DSCP value that has, and
after that the responder will know to which group this SA should be.
Other option is to send a Notify payload while creating SA, where you
list the DSCP values you will be sending in this SA, so the responder
can use that information to populate the SAD. The RFC4301 "4.4.2.1.
Data Items in the SAD" describes that each SAD entry has a list of
DSCP values that are put to this SA.
If the SA used for those DSCP values is deleted then SA which do not
list DSCP values will be used (i.e., the fall back SA). If there is no
SA that does not list DSCP values, then the RFC4301 does not really
specify which SA is used, but I would assume it could use any SA.
> We can also argue that this does not prevent managing tunnels.
> Suppose peer A Deletes the tunnel associated to g1. It deletes SA1
> and in the same way it deletes the SA peer B is steering traffic g3
> to. Since Peer B knows that Peer A has chosen SA1 for g1, it can
> notice that g1 does not need to be considered so the SA3 has one
> unused SA and that g3 may use instead SA3.
The question I have why are the gateways deleting the SAs at randomly?
Usually you simply rekey the SA, not just randomly delete some SA.
Things are much easier if implementations do smart things.
So the answer to this question is "please peer A, do not delete the
SA, rekey it"...
> As a result, this makes it possible to partition DSCP values into m
> categories over m distinct pairs of SAs. It could be convenient if
> we could create m pairs of SAs in one shot in which case we could
> also provide the DSCP partition and let the two peer to select their
> favourite SA. However, things look more complex when we are creating
> SAs one by one, and only once we have created the SAs, we could
> mention the DSCP partition into m partition as well as the m (or 2
> m) SPIs being considered. It also seems that each peer will need to
> monitor which DSCP is associated with which unidirectional SA.
I think the easiest way of doing that is to add DSCP Status Notify and
use it like this:
Initiator Responder
---
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2,
TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
This will create fall back SA for all traffic, meaning all traffic
regardless of DSCP values goes through this one.
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Paul Wouters writes: > On Mon, 7 Aug 2023, Tero Kivinen wrote: > > > Of course the optimal solution would be the original sender to not > > send 2000 byte packets, but instead fragment the packet already > > himself to 1300 bytes and 700 bytes, but that would require changes to > > the application and might not be that easy to do... > > And you think all these VPN gateways kernel stacks handling and tracking > and communicating upstrean to IKE to relay the message will be easier? Of course all proper VPN gateway products do that. They already do similar things when making sure ICMP error messages are processed correctly and end in correct tunnel, and that ICMP error messages for tunneled packets are processed so that they will trigger relevant ICMP messages sent to the proper hosts at correct time, and that fragment processing is done correctly etc. All of those are described in the RFC4301, and proper gateways implement them... And then there is linux :-) > I think people will just put mtu=1300 in their VPN config, use this new > notify and now we have yet another uncontrolled, unfixable hardcoded > packet size that will never go away again. And then there is linux :-) > The problem really is "create a 2000 byte packet and expect it to go > over the internet". Don't do that. If I remember right, at least NFS over udp does that (or it might use 8k packets), if I remember correctly... Nobody should be running NFS over udp over internet anyways, but it can happen over VPN links... Of course if you use IPv6 you do not have fragment in the middle issue, but even then you might have IPv6 packets inside the IPv4 ESP tunnel and end up in similar issues. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
Michael Richardson writes: > I'm not sure how we put more than 255 bytes in :-) > I guess it doesn't really matter if we call it padding or not, so we can > really just do whatever. I was just assuming rest of the packet is "Payload data": 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Payload Data (variable)| ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (i.e., there is no padding, pad length, next header, or ICV fields at all with this fixed SPI of 0x7. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification
Paul Wouters writes: > > You can't do that if DF=1, or IPv6. > > You can form big ESP packets and then fragment them, even with IPv6. > > DF=0 for IPv4 on ESP packets is good, until there is a firewall that cant > > cope with fragments. > > Why does any of this even matter? The applications should use > PLPMTUD / DPLPMTUD ? That is fine if application can adjust the packet size... Lets say someone runs application protocol that sends 2000 byte UDP packets between the hosts. When those 2000 byte packets are sent over the first hop the system might be using setup where the MTU is over 2000 so they are sent as one packet. Then it reaches the normal ethernet with 1500 byte MTU, and the that 2000 byte packet gets fragmented to 1500 and 500 byte fragments. Next it arrives to the VPN gateway. VPN gateway will take the 1500 byte fragment and realize that after adding ESP header it does not fit to the 1500 byte MTU anymore, thus it fragments the packet BEFORE encryption to two packets, one for 1400 bytes and another for 100 bytes. Then it encrypts the 1400 byte packet, adds an ESP header and sends it out. Now it crosses the internet and somewhere there some router in the middle is having MTU that is 1400 bytes, and as the packet does not have DF bit set, that router fragments the ESP packet again to 1300 byte packet and 100 + ESP overhead byte long packet. The 2nd fragment of the origina packet was only 100 bytes, so it passes without issues The 2nd fragment of the original packet (500 bytes) is now 3rd fragment and is processed by the VPN gateway and it fits the MTU, i.e., VPN geteway encrypts it and adds an ESP header and sends it out. This packet will go through the network without any extra fragmentation. So now there is 4 packets to be received by the VPN gateway, an 1st fragment of the orignal packet which consist of ESP packet fragmented in two pieces, one 1300 bytes, and another ~140 bytes, and two ESP packes containing 2nd and 3rd fragments of the original packets, with sizess of 100 bytes, and 500 bytes. Now the receiving VPN gateway will see that it is getting fragmented ESP packets, and it needs to do reassembly before it can decrypt that fragmented ESP packet. If the sender VPN gateway would have know that someone will fragment his 1400 byte ESP packet he could have used split the original 1500 byte fragment differently and reduced the extra work for everybody. So if the receiving VPN gateway will send this LMAP notify to the sender VPN gateway saying that it is seeing someone in the network doing framentation on the ESP packets and the biggest packet it is seeing is 1300 bytes, then the sending VPN could simply use that information when it is fragmenting the packets before encrypting them. I.e., when it next time gets 1500 byte fragment it will not fragment it to refragment it to 1400 + 100 byte fragments, but instead use 1300 + 200, and after that the in the future the receving VPN gateway will not receive fragmented ESP packets. There final destination will still receive fragments, but instead of receiving them having sizes of 1400 + 100 + 500, it will receive them having sizes of 1300 + 200 + 500. If the sender VPN would use DF=1 for outgoing packets it would also get the same information from the network, but as the draft says you can't really trust getting those ICMP packet too big notifications through the network for the sender VPN gateway. And if you do not get those ICMP messages, then packets will get silenty dropped. Of course the optimal solution would be the original sender to not send 2000 byte packets, but instead fragment the packet already himself to 1300 bytes and 700 bytes, but that would require changes to the application and might not be that easy to do... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
Michael Richardson writes: > > Tero Kivinen wrote: > > I think we should use normal ESP format i.e. have ESP SPI using > > following format: > > I mostly agree. > But: > > > (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | > > It would be nice to be able to put enough padding to make packets at least > 1280, ideally 2048 bytes in size. > > that would let us diagnose MTU issues better. That (0-255 bytes) is leftover from the figure I copied from the RFC4303, where it was part of the length of the padding field. In my case I did assume that payload can be of any length, so I agree on your fix... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt
Antony Antony writes: > Thanks Lorenzo for this ID. > I believe this is a great idea. Perhaps we could consider allowing a > non-zero ESP payload size? This would facilitate correlating responses upon > arrival at the sender. Then I would add an ESP message, format similar to > ICMP message. For instance, incorporating an identifier, like ICMP ping has, > would enable initiating multiple ESP pings from the same client and > receiving corresponding responses without mixing them up. I think we should use normal ESP format i.e. have ESP SPI using following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Payload Data* (variable) | ~ ~ | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding (0-255 bytes) | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integrity Check Value-ICV (variable)| ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where SPI = 0x0007/0x0008 Sequence number is just 32-bit sequence number (always present, can be used when correlating request to response). Payload data/padding is can be any length in reqeust and is always copied in response, i.e., it can be used as nonce/cookie to make sure nobody out side the path can fake responses. There would not be padding or next header fields, and the ICV field would be zero length. The final payload would look: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Payload Data* (variable) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPSECKEY errata item
There is one errata item for IPSECKEY WG: https://www.rfc-editor.org/errata/eid7402 This errata correctly identifies that the algorithm fields is 8-bit field, not 7-bit field as shown in the figure. The section 5 IANA considerations of IPsec Keying Material in DNS RFC4025 already explain that: This document creates an IANA registry for the algorithm type field. Values 0, 1, and 2 are defined in Section 2.4. Algorithm numbers 3 through 255 can be assigned by IETF Consensus (see RFC 2434 [5]). I.e., explains that the algorithm field is indeed 8-bit field. This errata should be marked as verified. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPsecME errata items
We seem to have 3 open errata for IPsecME WG documents: https://www.rfc-editor.org/errata/eid6940 For IKEv2 RFC7296 changing "the field must be empty" -> "the SPI field must be empty" in the SPI Size field description in section 3.10 (the errata only says section ".10", when it should have been "3.10"). This errata should be marked as Verified. https://www.rfc-editor.org/errata/eid6339 This complains that "Curve25519 and Curve448 for IKEv2" RFC 8051, has Appendix A public keys for X25519 generated incorrectly. I am not able to verify this as I do not have code to verify the generated test vectors. If someone has code that can verify the test vectors, please do so and report here. https://www.rfc-editor.org/errata/eid6931 This note that was split out from the previous errata for RFC8031, is not really an errata but a comment for future revision RFC 8031. I think we could simply mark it as Held for document update, and solve the issue when someone decides to update RFC8031. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPsec Errata items
Checking on the errata items for the old IPsec WG I found these three: https://www.rfc-editor.org/errata/eid6953 This is against RFC2402 and the change is correct, there is wrong section reference 3.3.2 where it should b section 3.3.3. This should be marked as verified. https://www.rfc-editor.org/errata/eid7244 This is for RFC3526 and it says that Generator should not be 2, but this is incorrect. The group in the RFC is generated using the instructions frm the RFC2412 and that explains that number 2 is not technically a generator, but there are reasons to use it (APPENDIX E The Well-Known Groups of 2412): Using 2 as a generator is efficient for some modular exponentiation algorithms. [Note that 2 is technically not a generator in the number theory sense, because it omits half of the possible residues mod P. From a cryptographic viewpoint, this is a virtue.] This change would be break interoperability with old implementations and should be rejected. https://www.rfc-editor.org/errata/eid4709 This is for RFC4301 and tries to fix the ASN.1 in Appendix C. The proposed changes uses lines which are not part of the RFC4301, i.e., the "=" -> "::=" that are listed as needed to be done, are already in the RFC4301. Only other changes it does is to remove "-- DEFINED BY algorithm" from one location, but leave it in in few other places. It also chanegs the iso(1) org (3) dod (6)" to "iso(1) identified-organization (3) dod (6) which might be correct, but is not needed. I think this errata should be rejected. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-mglt-ipsecme-ts-dscp
Daniel Migault writes: > I am under the impression that if one wants to ensure that the agreed DSCP > value takes the right SA we need to check that. As a result, I am inclined to > have in any case a MUST be checked. I am wondering if we are expecting this > check to take a significant overhead ? I do not think there should be any need to check that agreed on DSCP values takes right SA. As the issue is that packets get dropped because of the replay window checks, then it does not matter which SA they use as long as the packets do not get dropped. The sender has incentive to send them in best possible SA to make sure they do not get dropped, but even that does not guarantee that someone in the network does not decide to process the packets differently by for example modifying the outer DSCP values in some way. > I do not see a major change between using TS and a Notify. In both > cases if the ts_dscp or the notify is not sent or not supported we > fall back to the old case. So I do not expect that ts_dscp updates > 4301 (maybe I am wrong). As a result, I am wondering what are the > advantages of using a notification as opposed to a TS ? There is big difference using traffic selectors and notify. First of all that traffic selector would need special handling and coding in the implementations to be understood at all. Old implementations would at best return traffic selector set which do not include that new traffic selector. On the other hand implementations might not be that well written to handle unexpected traffic selectors. This was fine with labeled ipsec as there it is assumed that both ends know that both ends will support new traffic selectors. I would not be suprised to find out that some implementations would NOT do that narrowing properly when presented new traffic selector type, and instead would return some fatal error. All current implemetations of the IKEv2 already knows that they need ignore all unknown status notifications thus old implementations getting DSCP notify would simply ignre it and the SA would be created fine. > I do not see any and I am wondering if there are other reasons than > that DSCP is not commonly used for access control. I have the > impression this will be implemented the same way. In any case, if > that is the reason I am wondering if we should restrict the draft to > DSCP or consider that in the future additional parameters can be > added or do we want to limiit it to DSCP ? DSCP is not access control it is giving hints to the router what type of traffic is going through and what kind of QoS processing that type of traffic might need. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-mglt-ipsecme-ts-dscp
Daniel Migault writes: > Let me know if that text addresses your concern or if you prefer a different > wording. I believe I should add some more specific references to 4301. Note, that RFC4301 already describes how to handle DSCP, and your draft would actually change mandatory features of RFC4301: In section 4.1 Definition and Scope of RFC4301 says: If different classes of traffic (distinguished by Differentiated Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the same SA, and if the receiver is employing the optional anti-replay feature available in both AH and ESP, this could result in inappropriate discarding of lower priority packets due to the windowing mechanism used by this feature. Therefore, a sender SHOULD put traffic of different classes, but with the same selector values, on different SAs to support Quality of Service (QoS) appropriately. To permit this, the IPsec implementation MUST permit establishment and maintenance of multiple SAs between a given sender and receiver, with the same selectors. Distribution of traffic among these parallel SAs to support QoS is locally determined by the sender and is not negotiated by IKE. The receiver MUST process the packets from the different SAs without prejudice. These requirements apply to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not cause problems with respect to IPsec processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation. However, if significant re-ordering of packets occurs in an SA, e.g., as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism. I.e., it already says senders SHOULD use different SAs, and MUST permit SAs with same selectors, and MUST process from each SA in same way. In section 4.4.1.2 Structure of an SPD Entry of RFC4301: - Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values -- applicable to tunnel mode SAs I.e., SPD has option to specify whether DSCP is copied from inner to outer or whether it is mapped using mapping array. In section 4.4.2.1 Data Items in the SAD of RFC4301: o DSCP values -- the set of DSCP values allowed for packets carried over this SA. If no values are specified, no DSCP-specific filtering is applied. If one or more values are specified, these are used to select one SA among several that match the traffic selectors for an outbound packet. Note that these values are NOT checked against inbound traffic arriving on the SA. o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values -- applicable to tunnel mode SAs. This feature maps DSCP values from an inner header to values in an outer header, e.g., to address covert channel signaling concerns. describes that each SAD entry already has an entry telling which DSCP values are allowed for this SA, i.e., the sender will sue this item to put packets with given DSCP values to speific SA, but it also says that receiver does NOT check those values. > And another concern. I think that this document tries to > improperly use existing mechanism. Traffic selectors negotiated > in IKE SA are part of IPsec access control mechanism - i.e. they > are used to cryptographically separate different types of > traffic (ftp, http, etc.) and to allow performing access control > (based on network characteristics). In my understanding, DSCP > doesn't specify any particular kind of traffic, so it's strange > to me to separate traffic based on its value. > > That said, I seem to understand the problem that you are trying > to solve (correct me if I'm wrong): you want to make sure that > if peer A uses SA1 for, say, high priority traffic, then peer B > also use this SA (and not, say, SA2) for high priority traffic. > > If this is the problem, then perhaps it's easier to just > introduce a new notify that will inform peer that this SA is > intended to be used for some traffic priority. If peer supports > this extension, it is supposed to also use this SA for this kind > of traffic (it if honors this proposal). So, move from strict > negotiation to just announcing. > > I think you are correct in what we are trying to achieve. Reading the text below, I think you are trying to more than just keep same DSCP values for both directions. > First let me state that we are open to alternate design. > > The issue with the notification is that there is no check on the > inbound
Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update
Tobias Brunner writes: > It already states in section 3: "Non-optimized, regular rekey requests > MUST always be accepted." ... > So you're saying some configs, that are valid for regular IKEv2, will > just not work with this extension? And we'll only know once there is Combining those two, I think this is fine. I.e., this is optimization and it does NOT NEED to optimize every single possible configuration. We can clearly state that if you are using certain configurations you can't use this optimization, and have to fall back to normal rekey. For example we could say that if you are negotiating multiple protocols (AH + ESP or ESP + IPCOMP), or if you are using anything else than one single KE algorithm for create child sa, you need to use regular rekey. > The only way to avoid that would be the extension either making > childless IKE SAs mandatory, or strictly prohibiting inconsistent KE > configs between IKE and Child SAs, taking away quite a bit of > flexibility IKEv2 offers. You do not need to make childless IKE SA mandatory, you simply need to do first rekey after initial sa creation using normal rekey, and if that normal rekey has SA/KE payloads that are acceptable for the optimized rekey in the future, then you can use optimized rekeys in the future. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPsecME WG Agenda for IETF 117
Tero Kivinen writes: > It seems our agenda is already full. I would like to get slides for > all presentation during next week, i.e. before the 14th Friday > evening. Updated version of the agenda, with some presentator changed: -- IP Security Maintenance and Extensions (IPsecME) WG. IETF 117 - Wednesday July 28th, 2023 15:30-17:00 PDT https://meetings.conf.meetecho.com/ietf117/?group=ipsecme==1 Agenda - Note Well, technical difficulties and agenda bashing - Chairs (5 min) - Document Status - Chairs (10 min) - Other items - IKEv2 Optional SA Payloads in Child Exchange (15 min) Paul Wouters draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt - An RPKI and IPsec-based AS-to-AS Approach for Source Address Validation (10 min) Ben Schwartz draft-xu-ipsecme-risav - Traffic Selector for IKEv2 to add support DSCP (5 min) Daniel Migault draft-mglt-ipsecme-ts-dscp - IKEv2 Link Maximum Atomic Packet and Packet Too Big Notification Extension (5 min) Daniel Migault draft-liu-ipsecme-ikev2-mtu-detect - Diet ESP: ESP Header compression, IKEv2 EHC (5 min) Daniel Migault draft-mglt-ipsecme-ikev2-diet-esp-extension draft-mglt-ipsecme-diet-esp - Anti-replay sequence number subspaces for traffic-engineered paths and multi-core processing (10 min) Mohsin Shaikh draft-ponchon-ipsecme-anti-replay-subspaces - Use of Reliable Transport in the IKEv2 (10 min) Valery Smyslov draft-smyslov-ipsecme-ikev2-reliable-transport - Problem statements and uses cases for lightweight Child Security Associations (10 min) Steffen Klassert draft-mrossberg-ipsecme-multiple-sequence-counters - Adoption calls (5 min) - draft-smslov-ipsecme-ikev2-qr-alt - draft-mglt-ipsecme-ts-dscp - draft-liu-ipsecme-ikev2-mtu-dect - draft-mglt-ipsecme-diet-esp - draft-mglt-ipsecme-ikev2-diet-esp-extension - draft-smyslov-ipsecme-ikev2-cookie-revised - AOB + Open Mic (0 min) -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IPsecME WG Agenda for IETF 117
Paul Wouters writes: > On Jul 14, 2023, at 08:21, Tero Kivinen wrote: > > > > It seems our agenda is already full. I would like to get slides for > > all presentation during next week, i.e. before the 14th Friday > > evening. > > I take it you mean July 21, and not today Yes, of course... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPsecME WG Agenda for IETF 117
It seems our agenda is already full. I would like to get slides for all presentation during next week, i.e. before the 14th Friday evening. -- IP Security Maintenance and Extensions (IPsecME) WG. IETF 117 - Wednesday July 28th, 2023 15:30-17:00 PDT https://meetings.conf.meetecho.com/ietf117/?group=ipsecme==1 Agenda - Note Well, technical difficulties and agenda bashing - Chairs (5 min) - Document Status - Chairs (10 min) - Other items - IKEv2 Optional SA Payloads in Child Exchange (15 min) Paul Wouters draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt - An RPKI and IPsec-based AS-to-AS Approach for Source Address Validation (10 min) Yangfei Guo draft-xu-ipsecme-risav - Traffic Selector for IKEv2 to add support DSCP (5 min) Daniel Migault draft-mglt-ipsecme-ts-dscp - IKEv2 Link Maximum Atomic Packet and Packet Too Big Notification Extension (5 min) Daniel Migault draft-liu-ipsecme-ikev2-mtu-detect - Diet ESP: ESP Header compression, IKEv2 EHC (5 min) Daniel Migault draft-mglt-ipsecme-ikev2-diet-esp-extension draft-mglt-ipsecme-diet-esp - Anti-replay sequence number subspaces for traffic-engineered paths and multi-core processing (10 min) Pierre Pfister draft-ponchon-ipsecme-anti-replay-subspaces - Use of Reliable Transport in the IKEv2 (10 min) Valery Smyslov draft-smyslov-ipsecme-ikev2-reliable-transport - Problem statements and uses cases for lightweight Child Security Associations (10 min) Steffen Klassert draft-mrossberg-ipsecme-multiple-sequence-counters - Adoption calls (5 min) - draft-smslov-ipsecme-ikev2-qr-alt - draft-mglt-ipsecme-ts-dscp - draft-liu-ipsecme-ikev2-mtu-dect - draft-mglt-ipsecme-diet-esp - draft-mglt-ipsecme-ikev2-diet-esp-extension - draft-smyslov-ipsecme-ikev2-cookie-revised - AOB + Open Mic (0 min) -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IETF 117 agenda items
Send requests for IETF 117 IPsecME agenda items to the ipsecme-cha...@ietf.org by the end of this week, so I can create the agenda for the IPsecME WG next week. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKEv2: how to respond to REKEY_SA with bad protoid?
Andrew Cagney writes: > > Also the section 3.10 of RFC7296 says: > > > > o Protocol ID (1 octet) - If this notification concerns an existing > > SA whose SPI is given in the SPI field, this field indicates the > > type of that SA. For notifications concerning Child SAs, this > > field MUST contain either (2) to indicate AH or (3) to indicate > > ESP. Of the notifications defined in this document, the SPI is > > included only with INVALID_SELECTORS, REKEY_SA, and > > CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be > > sent as zero and MUST be ignored on receipt. > > I assume we're not discussing 0 or 1(IKE). Which should be dismissed with >INVALID_SYNTAX7 >Indicates the IKE message that was received was invalid because >some type, length, or value was out of range or because the >request was rejected for policy reasons. REKEY_SA is only used when rekeying Child SAs, i.e., it is NOT used when rekeying IKE SA. > I like the principal. As things go forward and exchanges for new > protocols are defined they each get to spell out the details of things > like the proposal sub payload > and how to extract the Child's identifying material from the REKEY_SA. > > Several things trouble me: > > The first is that the RFC only defines how to extract the child's > identifier for ESP and AH vis: > >o SPI Size (1 octet) - Length in octets of the SPI as defined by the > IPsec protocol ID or zero if no SPI is applicable. For a > notification concerning the IKE SA, the SPI Size MUST be zero and > the field must be empty. > > which means that for a completely unknown protocol I'm left assuming > the notify body is ESP/AH like (is SPI length = 8 reasonable? Is SPI > length = 0 with a 32k blob reasonable?). > (I understand one implementation sends back an empty child-not-found > notify, which at least avoids the need to parse the body). If someone proposed to rekey protocol id that the receiving end does not support, it means the other end is broken and is not following the RFC. There is no way there could be and unknown protocol id already negotiated between the peers if this peer does not recognize the protocol id. So either option is correct, either return CHILD_SA_NOT_FOUND and copy protocol id, spi size, and spi from the REKEY_SA, or return INVALID_SYNTAX and tear down the IKE SA. Receiving unknown protocol id in rekey sa is clearly a bug in the other ends implementation so it does not really matter what you are doing, the other end should fix their code... > The second is that the peer is trying to rekey a Child SA that can > never exist. Any attempt to establish this new unknown protocol > should have failed as the proposal sub-payload containing the unknown > protocol would be ignored. I view that as pretty broken, or worse. Yes. > Hence, when the protocol is completely unknown I se invalid-syntax as > being an equally valid response. In some implementations I know the policy of what protocol ids were known and what kind of SPIs they are using was passed to the policy module, i.e., the IKE module would never return that protocol id would not be valid, as it did not know which protocol ids are valid and which are not. The policy module was doing that checking. In such cases it would be logical to the policy module to return CHILD_SA_NOT_FOUND error. Note, that the policy module could be dynamically loaded, and there could have been support for such protocol id earlier (for example before reboot and updating the system). If the policy module and IKE is tightly integrated, meaning that IKE will immediately known that this protocol id cannot exists, thus it can return INVALID_SYNTAX if it feels like it. We usually do not mandate specific error codes to be used, as different implementations can have different ways of checking things. I.e. one implementation might do lookup based on protocol id + spi without checking protocol id at all, and if no such match is found it will return CHILD_SA_NOT_FOUND. Only after passing that it would start looking actual value of the protocol id... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] IKEv2: how to respond to REKEY_SA with bad protoid?
Tobias Brunner writes: > > The SA that the initiator attempted to rekey is > >indicated by the Protocol ID and SPI fields in the Notify payload, > >which are copied from the Protocol ID and SPI fields in the REKEY_SA > >notification. > > Hm, I just noticed that we (strongSwan) implement that incorrectly as we > send the CHILD_SA_NOT_FOUND notify without SPI (or protocol ID). What's > the purpose of repeating that information in the notify? There can only > be a single REKEY_SA notify in the request, so how could there be any > confusion for the exchange initiator about which SA wasn't found by the > responder? I do not think there is any real purpose, but the cases where you need to return CHILD_SA_NOT_FOUND usually means something unexpected happened, and repeating the information might be helpful for debugging that case. The text was added in the draft-ietf-ipsecme-ikev2bis-07 when creating RFC5996 (January 2010), and has not been changed since... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IKEv2: how to respond to REKEY_SA with bad protoid?
Paul Wouters writes: > > We ran into an issue where we received a REKEY_SA notify with a bad > protocol id, eg not ESP or AH. What do we do? > > 1) CHILD_SA_NOT_FOUND, but what should we put in the proto id field? > 0 ? the bogus value? > 2) It's bad, so INVALID_SYNTAX > > When doing 1, we will see: > > Responder uses bad protocol id - Initiator can quietly delete child sa. > But it forces us to send something violating the RFC. > > Or Responder uses ESP or AH protocol id? Initiator will now be upset, > and possible send a new informational with a notify with INVALID_SYNTAX > or DELETE. If INVALID_SYNTAX, it will take down everything. > > When doing 2, it guarantees everything will be taken down. > > > Ideally, we would like to "ignore" the REKEY_SA, and leave the IKE and > existing Child SAs up. But that means we need to lie about protocol id, > and we currently have guards in our code to protect against that. If you use invalid syntax and tear down the SA, then at least the other end will know that they are doing something wrong and hopefully they will fix their code at some point. But I think correct option is to use exactly same protocol id than what the initiator used, as that is what SA they are trying to use. The Child SA is identified by the protocol id and spi tupple, so if you do not have matching child sa, returning CHILD_SA_NOT_FOUND is the correct, and as in the section 2.25 the RFC7296 says: A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a request to rekey a Child SA that does not exist. The SA that the initiator attempted to rekey is indicated by the SPI field in the Notify payload, which is copied from the SPI field in the REKEY_SA notification. A peer that receives a CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child SA (if it still exists) and send a request to create a new Child SA from scratch (if the Child SA does not yet exist). If the protocol id does not match the protocol id you are using, then you do NOT HAVE matching Child SA, thus the other end is trying to rekey sa that does not exists. I.e. the SPI field is copied from the REKEY_SA to CHILD_SA_NOT_FOUND notify, then you needs to copy the protocol id too... Also the section 3.10 of RFC7296 says: o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS, REKEY_SA, and CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. thus the Protocol ID field indicates the protocol id for the SA indicated by the SPI field, thus Protocol ID and SPI are always going together, and as REKEY_SA and CHILD_SA_NOT_FOUND are those few ones that have Protocol ID and SPI non-zero you need to copy them. You could submit an errata saying that The SA that the initiator attempted to rekey is indicated by the SPI field in the Notify payload, which is copied from the SPI field in the REKEY_SA notification. should say The SA that the initiator attempted to rekey is indicated by the Protocol ID and SPI fields in the Notify payload, which are copied from the Protocol ID and SPI fields in the REKEY_SA notification. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPsecME WG report from IETF 116
This is the copy of the status update already posted to the datatracker: https://datatracker.ietf.org/group/ipsecme/about/status/ -- IPTFS (base draft, and yang and mib drafts), TCP Encapsulation (rfc8229bis) were published as RFC. Multiple ke is in the IESG evaluation, and deprecation of IKEv1 and obsolete algorithms drafts are now in RFC editor queue. Labeled IPsec is in the IETF Last call, and IKEv2 Configuration for Encrypted DNS is waiting for AD followup. Group Key Management still would benefit from more reviews, we got one partial one, and few people has promised to do reviews. Submit the draft for early directorate review to get more reviews for it, and then submit it for publication. Announcing Supported Authentication Methods in IKEv2 got some comments, and needs a new revision. After that is done it is ready for 2nd WGLC. The Optional SA & TS Payload in Child Exchange, and multi sa performance are adopted as WG drafts, and the there has been some implementation testing of the first one, which has resulted several new questions and change requests to the draft. There has been some interest on the alternate approach for mixing preshared keys in ikev2 for post-quantum security, and there will be WG adoption call will be done after the open issues of the draft are solved, and new version is posted. Quite a lot of charter items have been finished, so we should start working on to do rechartering, and clear out old things already finished, and add some new work to the charter. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Slices for the presentations
If you presenting in the IPsecME in IETF 116, please post your slides in pdf format with page numbers to the datatracker by the end of Monday. No slides posted, no time in agenda... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
mohamed.boucad...@orange.com writes: > As you can see at https://tinyurl.com/add-ike-latest, the note is > updated as follows: > > Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) > attribute to be mandatory present when INTERNAL_DNS_DOMAIN is > included. This specification relaxes that constraint in the > presence of ENCDNS_IP* attributes. That is, if ENCDNS_IP* > attributes are supplied, it is allowed for responders to include > ^^ > INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS (or > INTERNAL_IP4_DNS) attributes. > > Thanks for zooming into this. I was expecting to have this > discussion during the IESG review. We have now a fresh thread to > which we can refer :-) That looks good, and solves the issue I had with backward compatibility. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
Valery Smyslov writes: > > I mean if initiator proposes: > > > >CP(CFG_REQUEST) = > > INTERNAL_IP6_ADDRESS() > > ENCDNS_IP6() > > ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512)) > > INTERNAL_DNS_DOMAIN() > > > > to indicate that it only wants to talk ENCDNS server, and it does NOT > > want to have normal DNS server, then responder who do not understand > > ENCDNS_IP6() will see that this is against MUST in RFC8598 and as > > there is no other error to use, it will most likely consider this a > > malformed message (==fatal error) and return with INVALID_SYNTAX. This > > will tear down the IKE SA and does not specify for the initiator why > > the connection attempt failed. > > The initiator cannot force the responder to do anything (e.g. to > explicitly provide it with the encrypted DNS info). It can only > indicate support for this feature. So, in my understanding, the > above set of configuration attributes indicates some problems with > initiator (in which case fatal error is not a bad solution). > > The correct request should be: > > CP(CFG_REQUEST) = > INTERNAL_IP6_ADDRESS() > INTERNAL_IP6_DNS() > ENCDNS_IP6() > ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512)) > INTERNAL_DNS_DOMAIN() > > If the responder doesn't support this extension, it will ignore > ENCDNS_IP6 and ENCDNS_DIGEST_INFO and return INTERNAL_IP6_DNS(...) + > INTERNAL_DNS_DOMAIN(...). > > If the responder supports this extension, it will return either > ENCDNS_IP6(...) + ENCDNS_DIGEST_INFO(..) + INTERNAL_DNS_DOMAIN(...) > or INTERNAL_IP6_DNS(...) + INTERNAL_DNS_DOMAIN(...) depending on its > configuration (most probably the former). This is all clear. > If the initiator is configured to allow only encrypted DNS, it may > immediately delete IKE SA in case the responder returns > INTERNAL_IP6_DNS. There is nothing more the initiator can do in this > case. > > Note, that with this approach there is no room for fatal errors, all > protocol paths are legal with no need to update 8598. Ok, so the note for RFC8598 behavior only applies to responder, i.e., responder is allowed return ENCDNS_IP* and INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but inititiator needs to send request that contains both. Perhaps the Note about the RFC8598 should be updated to say "it is allowed for responder to include INTERNAL_DNS_DOMAIN even in the absense of INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes, provided there is ENCDNS_IP* attributes in the response." or something like that. Then I agree that this does not update RFC8598. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
mohamed.boucad...@orange.com writes: > > But my understanding is that this is not the case here, as if you > > send INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with > > ENCDNS_IP* to implementations supporting old RFC, > > [Med] Responders know when it will break. They will basically supply > the encrypted DNS to initiators who indicated support as per: > >Initiators first indicate support for encrypted DNS by including >ENCDNS_IP* attributes in their CFG_REQUEST payloads. Responders >supply encrypted DNS configuration by including ENCDNS_IP* attributes >in their CFG_REPLY payloads. > > If responders decide to ignore the capabilities of the initiators, > returning **only** the ENCDNS_IP* won't break only split horizon but > the full DNS service! I mean if initiator proposes: CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() ENCDNS_IP6() ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512)) INTERNAL_DNS_DOMAIN() to indicate that it only wants to talk ENCDNS server, and it does NOT want to have normal DNS server, then responder who do not understand ENCDNS_IP6() will see that this is against MUST in RFC8598 and as there is no other error to use, it will most likely consider this a malformed message (==fatal error) and return with INVALID_SYNTAX. This will tear down the IKE SA and does not specify for the initiator why the connection attempt failed. Note, that RFC8598 says that responder must return INTERNAL_IP*_DNS if INTERNAL_DNS_DOMAIN is present, but if the initiator does not offer them it can't add them. Thats why it would be better for even those RFC8598 implementations which will not support this RFC to be modified so that they will understand ENCDNS_IP* at least so much that they understand that they can ignore INTERNAL_DNS_DOMAIN attribute if there is no INTERNAL_IP*_DNS, and but there is ENCDNS_IP* instead. If they simply ignore ENCDNS_IP* (is they should, as they do not understand), and they ignore the INTERNAL_DNS_DOMAIN also because there is no INTERNAL_IP*_DNS then the initiator will be able to connect. And then the initiator can later do another configuration payload to fetch normal DNS servers ip-addresses if those would be acceptable for it. Or, have I misunderstood the protocol somehow. I.e., what should old responder implementation do when it receives the request like above? -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Dnsdir last call review of draft-ietf-ipsecme-add-ike-09
mohamed.boucad...@orange.com writes: > > At the IETF process level, which I don't master, because of last > > note in §4, shouldn't that document explicitly say it updates > > RFC8598? > > [Med] We discussed this point at the time (and I was personally for > adding the header), but we didn't because the convention in ipsecme > WG is to not add the Update header if implementations are clearly > able to distinguish the cases when an extension is being used even > if the extension would change the behavior defined in the existing > RFCs. In this spec, if the initiator receives any of ENCDNS_IP* > attributes, it will know that it should not expect the > INTERNAL_IP*_DNS even if it receives INTERNAL_DNS_DOMAIN too. The > note you are referring to is to make that clear. I think we usually use updates header if implementations supporting old RFC but not this, needs to change their behavior. I.e., if we just add new attributes, and the implementations of old RFC simply ignore them then everything is fine. But my understanding is that this is not the case here, as if you send INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with ENCDNS_IP* to implementations supporting old RFC, then that RFC will consider this as a fatal error, and tear down the whole IKE SA, instead of silently ignoring ENCDNS_IP* and INTERNAL_DNS_DOMAIN attributes. So in this case it would be better for the old Split DNS Configuration for IKEv2 RFC8598 implementations to be changed in a way that they recognize this situation and do not consider it as a fatal error. Update to the RFC8598 would not be needed if the RFC8598 implementations would simply ignore both the INTERNAL_DNS_DOMAIN and ENCDNS_IP* in configuration payload, but I do not think that is the case here. So question is not whether it is possible to recognize the situation, it is what happens when you combine new and old implementations. If things works without a need to change old implementations then no updates is needed, if you need to update the old implentations too, then you do need updates header. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPsecME Agenda
We have received requests for enough items to fill in the IPsecME WG meeting slot, so here is the preliminary agenda for the IPsecME WG: If you have any additional items that you would like to discuss, then we need to start to tune down some of the presentations. -- IP Security Maintenance and Extensions (IPsecME) WG. IETF 116 - Wednesday March 29th, 2023 15:30-17:00 JST https://meetings.conf.meetecho.com/ietf116/?group=ipsecme==1 Agenda - Note Well, technical difficulties and agenda bashing - Chairs (5 min) - Document Status - Chairs (15 min) - Work items - Issues SA TS Payloads opt draft Paul Wouters (10 min) - Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security Valery Smyslov (10 min) - Extended IKEv2 Payload Format Valery Smyslov (20 min) - Anti replay subspaces Mohsin Shaikh (10 min) - IKEv2 IPv4 Link Maximum Atomic Packet Notification Extension" Daniel Migault (10 min) - Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints Daniel Migault (10 min) - AOB + Open Mic (0 min) -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] [IANA #1267827] expert review for draft-ietf-ipsecme-add-ike (ikev2-parameters)
David Dong via RT writes: > Dear Tero Kivinen and Valery Smyslov (cc: ipsecme WG), > > As the designated experts for the IKEv2 Configuration Payload > Attribute Types registry, can you review the proposed registration > in draft-ietf-ipsecme-add-ike for us? Please see > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-add-ike/ > > The due date is March 20, 2023. > > If this is OK, when the IESG approves the document for publication, > we'll make the registration at > > https://www.iana.org/assignments/ikev2-parameters/ > > We'll wait for both reviewers to respond unless you tell us otherwise. The IANA allocations listed in the draft are ok. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Agenda for IETF 116
So now it is time to start sending agenda items for the IETF 116 IPsecME WG meeting. When you send your requests, please also include how much time you think you would need for your topic. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Disabling replay protection
Benjamin Schwartz writes: > On Mon, Feb 20, 2023 at 4:58 PM Michael Richardson wrote: > > Tero Kivinen wrote: > > I mean what should other end do if the other end says he will not > > do anti-replay checks? > > Not send unique relay values in the ESP. > > Yes but mostly for AH. My goal is related to draft-xu-risav, which would > benefit from the ability to repeat sequence numbers in AH when replay > protection is not required. ESP and AH already allow that if you have multi sender situations, but IKE does not allow nogotiating such SAs. If you use g-ikev2 to negotiate multicast multi sender sa then I think the anti-replay is already disabled. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Disabling replay protection
Michael Richardson writes: > Tero Kivinen wrote: > > I mean what should other end do if the other end says he will not > > do anti-replay checks? > > Not send unique relay values in the ESP. You can already do that on multicast SAs, but for unicast SAs the RFC4303 mandates the unique sequence numbers regardless whether the recipient checks it or not: For a unicast SA or a single-sender multicast SA, the sender MUST increment this field for every transmitted packet. and The field is mandatory and MUST always be present even if the receiver does not elect to enable the anti-replay service for a specific SA. Processing of the Sequence Number field is at the discretion of the receiver, but all ESP implementations MUST be capable of performing the processing described in Sections 3.3.3 and 3.4.3. Thus, the sender MUST always transmit this field, but the receiver need not act upon it (see the discussion of Sequence Number Verification in the "Inbound Packet Processing" section (3.4.3) below). Note, that the replay values might still not be unique, as if anti-replay is disabled then the sender can allow sequence number to cycle, thus using duplicate sequence numbers. This is not allowed if anti-replay is enabled. Only thing that could be allowed by telling the other end that anti-replay is disabled is that the sequence number is allowed to sycle: If anti-replay is disabled (as noted above), the sender does not need to monitor or reset the counter. However, the sender still increments the counter and when it reaches the maximum value, the counter rolls over back to zero. (This behavior is recommended for multi-sender, multicast SAs, unless anti-replay mechanisms outside the scope of this standard are negotiated between the sender and receiver.) Is that feature so important that we should have separate notification for it? If you want to do something else by negotiating the fact that you do not do anti-replay protection then we need to modify the ESP and AH too, not just add notification to IKE. So I am saying that I do not see any real use case for just adding notification to IKE. There could be other features that people want to add that would also require telling the other end that replay protection checks are disabled, but those changes would require more things than just one notification to ike. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Disabling replay protection
Benjamin Schwartz writes: > Hi IPSECME, > > RFC 4302 (ESP) says "if an SA establishment protocol such as IKE is employed, > the receiver SHOULD notify the sender, during SA establishment, if the > receiver will not provide anti-replay protection". > > I haven't been able to find any mechanism for this in IKEv2 (or IKEv1). Is > there a way to do this? Or is this a mismatch between ESP and IKEv2? I think we discussed this during the development of the IKEv2, and it was decided that as the replay protection is completely local matter, there is not really reason to have that kind of notification in IKEv2. I mean what should other end do if the other end says he will not do anti-replay checks? I think it would be stupid to reject such connections just because of that, and that could cause the other end to claim to do it and still not do it just to get through the negotiation. In IKEv2 we tried to remove all of those parameters which are only local matter, so that any differences in those do not cause the negotiations to fail. In IKEv1 there was for example the lifetime parameters sent inside the IKEv1, and they caused lots of interoperability issues, when one send life time of 86400 and the other one had life configured to 86700, because there was 24h lifetime + 5 minute grace period. Or other end had one hour and other had 8 hours. Trying to get both ends to agree on the exact lifetimes was difficult, and thats why we removed those in IKEv2. I think the anti-replay protection is similar matter. What is the actual real life reason you would want to know about that, and what do you want to do when they do not match? -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Publication has been requested for draft-ietf-ipsecme-labeled-ipsec-09
Tero Kivinen has requested publication of draft-ietf-ipsecme-labeled-ipsec-09 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-labeled-ipsec/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Shepherd write up review for draft-ietf-ipsecme-labeled-ipsec
I already send some comments, but now when I am checking the modified draft I found some other nits, that might need to be fixed at some point (I will still put the document forward today, authors can fix those later when they have time, or when they have other comments during the IETF last call etc). In section 2.2 we have text: If the Security Label traffic selector is optional from a configuration point of view, an initiator will add the TS_SECLABEL to the TSi/TSr Payloads. If the responder replies with TSi/TSr Payloads that include the TS_SECLABEL, than the Child SA MUST be created including the negotiated Security Label. If the responder did not include a TS_SECLABEL in its response, then the initiator (with deemed the Security Label optional) will install the Child SA without including any Security Label. If the initiator required the TS_SECLABEL, it MUST not install the Child SA and it MUST send a Delete notification for the Child SA so the responder can uninstall its Child SA. and in section 3 we have text: If a TS_SECLABLE is deemed optional, the initiator SHOULD first try to negotiate the Child SA with the TS payload including the optional TS_SECLABEL. If such a negotiation results in receiving a TS_UNACCEPTABLE Error Notify, it SHOULD attempt a new Child SA negotiation using the same TS but without the optional TS_SECLABEL. which do not match. I suggest just removing the section 3 text, as this is already explained in the section 2.2. Or perhaps moving the text from section 2.2 to section 3, replacing that old section 3 paragraph with the text moved from section 2.2. In the section 3.1 it would be nice to use properly formatted IP-addresses. Now it looks that you are negotiating some 24-bit FC-addresses, as your ip-addresse only has 3-bytes in them: TSi = ((17,24233,198.51.12-198.51.12), (17,0,192.0.2.0-192.0.2.255), (0,0,198.51.0-198.51.255), TS_SECLABEL1, TS_SECLABEL2) and TSi = ((0,0,198.51.0-198.51.255), TS_SECLABEL1) Replace 198.5.12 with something like 198.5.0.12 and 192.51.0 with 192.51.0.0 and 192.51.255 with 192.51.0.255 or something... There is also one 192.51.0/24 in Section 3.2 that should be changed to 192.51.0.0/24. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Publication has been requested for draft-ietf-ipsecme-add-ike-07
Tero Kivinen has requested publication of draft-ietf-ipsecme-add-ike-07 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-add-ike/ ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-add-ike-07.txt
mohamed.boucad...@orange.com writes:
> This version takes into account Tero's review, mainly:
>
> * Indicate the encoding of the addresses
> * Split the ENCDNS_DIGEST_INFO figure into two
> * Add some text about CFG_ACK
> * clarify how the digest is computed
> * Add some examples
>
> and some other minor edits.
Can you add the other examples we had in our email exachange for
different requests, I think they provide useful information.
Also in examples it is useful to actually use names instead of
numbers, thats why I had (SHA2-256, SHA2-384, SHA2-512), and not (2,
3, 4). We are not using numbers for CP, CFG_REQUEST, or any other
fields...
Using only numbers would get really annoying:
47(1) =
8()
10()
TBA2()
TBA3(0, (2, 3, 4))
:-)
And the ADN length field of the CFG_REPLY example is wrong, it says
16, but "doh.example.com" is only 15 characters long. Thats why my
example was using doh1.example.com :-)
I.e. it should be:
CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:db8:0:1:2:3:4:5/64)
ENCDNS_IP6(1, 1, 15,
(2001:db8:99:88:77:66:55:44),
"doh.example.com",
(alpn=h2 dohpath=/dns-query{?dns}))
ENCDNS_DIGEST_INFO(0, SHA2-256,
8b6e7a5971cc6bb0b4db5a71...)
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike
mohamed.boucad...@orange.com writes: > [Med] Yes, the initiator may include a suggested ALPN (protocol) for > example to specifically indicate it is looking for DoT (or another > protocol). The initiator may omit the ADN, but only include service > parameters (typically, ALPN) to indicate a preferred transport > protocol. I was assuming there is some way of indicating that, but I could not quickly find any examples of that, that is why I wanted to have more examples in this draft, so I could see what values the alpn can have :-) > > > > > CP(CFG_REQUEST) = > > ENCDNS_IP6(23, 1, 16, > > (2001:DB8:99:88:77:66:55:44), > > "doh1.example.com", > > "???") > > > > initiator requesting the responder for specific information, most > > likely something that it got last time, and initiator proposes it > > to the responder, in case it is still valid, and responder can > > send that same information back if it is valid, or return > > something else. > > [Med] Yeah, but still this is just a suggested value and it is up to > the responder to decide to honor it or not. If a preference does not > make sense, the response will simply ignore it. Yep, this is standard IKEv2 behavior. > > Btw, for the second use case where the initiator fills in some of > > the information about the server it wants to talk to, it would be > > usefull to allow Service Priority to be 0, and explictly mention > > that this is not AliasMode, this is meaning that initiator does > > not care about the exact priority or does not know the priority, > > so it used 0 as placeholder. > > [Med] The initiator can use any non-null value for the priority in > such case. No need to relax the constraint imposed on svcpriority. My guess is that people are going to use zero still, as that is the obvious number to use, which is why I think it would be better to allow that... As long as responders do not start checking that CFG_REQUEST priority must be non zero everything is fine... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike
mohamed.boucad...@orange.com writes: > > of the cases the information in IANA registries are already in the > > normative reference RFCs > > RFCs may include stale/inaccurate values (e.g., new/deprecated > values). The IANA registry is authoritative. Yes, but you only need one value to actually implement standard. You do not need to know all currently supported values. I would assume that implementators will go to the IANA regardless whether ther reference is normative or informative. > I still think maintaining the refs as they are is aligned with > https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/. Yes, most likely, but ID nits still complains about it. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] IETF 114 IPsecME report
Valery Smyslov writes: > Hi Tero, > > few comments inline. > > [a lot of text snipped] > > > This document should simply say that TS_SECLABEL MUST NOT be used > > alone. This document must not try to do incompatible change to the > > base RFC7296 which would make conforming implemntations > > non-conforming. > > Unfortunately, this won't work. It is not enough to add new TS type, > with security labels the semantics of TS types should be changed > so, that there are "primary" TS types and "additional" ones. Yes, but that change should not affect any other TS type than TS_SECLABEL. > This is because in RFC 7296 individual Traffic Selectors in TS payload > are combined with OR. In other words, traffic matching > combination of any Traffic Selector in TSi and > any Traffic Selector in TSr is protected. > > TS_SECLABEL cannot be treated with this semantics, > it must be treated with AND (as additional condition for > the traffic to match), which requires RFC 7296 update. No it does not. Nothing in this RFC will change any behavior of any of the existing implementations, and there is no need for existing implementations to be updated to this AND behavior. Only implementations who implement TS_SECLABEL need to know the special processing of it. If the initiator does not support TS_SECLABEL, it will never send them, and there is no issues. If the responder requires TS_SECLABEL it will return TS_UNACCEPTABLE, and the negotiation fails. If the initiator does support TS_SECLABEL, but responder does not, then it will send TS_IPV*_ADDR_RANGE and TS_SECLABEL, and the responder will only return with TS_IPV*_ADDR_RANGE. The initiator should notice there is no TS_SECLABEL, and if that TS_SECLABEL was mandatory then it should delete the SA, and fail the negotiation. As the responder does not support TS_SECLABELs, there is no security issue for it sending data to IPsec SA, as it does not support security labels that would forbid such operation. As the initiator never installs the SA which does not have proper TS_SECLABEL there is no security issues there as it will never receive or send any traffic to that SA that got deleted immediately as it was never installed. So the text in draft saying: If the Security Label traffic selector is optional from a configuration point of view, the initiator will have to choose which TS payload to attempt first. If it includes the Security Label and receives a TS_UNACCEPTABLE, it can attempt a new Child SA negotiation without that Security Label. does not match with that it needs to be updated to: If the Security Label traffic selector is optional from a configuration point of view, the initiator will try with TS_SECLABEL. If the responder includes TS_SECLABEL, then IPsec SA with that Security Label got created. If the responder did not include TS_SECLABEL in its response, then it does not support (or its policy does not allow) them, thus if the TS_SECLABEL was optional in the initiator then it can accept that SA. If the TS_SECLABEL was mandatory in the initiator policy, then it MUST not install the SA, and MUST send delete the Child SA using Delete notification. I.e., there is no need for it to try with two different CREATE_CHILD_SA exchanges, it can simply try with one, that has both TS_IPV*_ADDR_RANGE and TS_SECLABEL, and responder will return either TS_IPV*_ADDR_RANGE only or both. If the responder does not support TS_SECLABEL, it will never pick that one, and if it does support TS_SECLABEL, it knows it MUST NOT return only that, it also needs to include TS_IPV*_ADDR_RANGE selectors. I rather have the complications of processing TS_SECLABEL in the implementations that support it, and not cause all old implementations to suddenly be non-conforming as they do not follow this MUST added here: A responder MUST create each TS response by creating one of more (narrowed or not) TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE entries, plus one of each further TS_TYPE present in the offered TS by the initiator. If this is not possible, it MUST return a TS_UNACCEPTABLE Error Notify payload. I.e., that it MUST return all other TS_TYPEs or if it does not understand them it MUST return TS_UNACCEPTABLE... This makes adding TS_TYPES really hard in the future, as if we add TS_MY_TEST_TYPE, then every single implemenation will always return TS_UNACCEPTABLE to me if it does not support it, and I must do two exchanges one with it, and another without it if the first one fails. > I agree with you that current document text doesn't take into > considerations the existence of other "primary" TS types, like > TS_FC_ADDR_RANGE. I think all TS types are "primary" except this TS_SECLABEL one as this is how RFC7296 defines them. y > > So I do not think this document should update RFC7296 at all, so most > > of the section 3 is wrong. > > The "proper" way would be to introduce new TS types > TS_IPV4_ADDR_RANGE_WITH_SECLABEL and
Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike
mohamed.boucad...@orange.com writes: > > > Also the text in Num Addresses indicate that it would be valid > > to send > > > CFG_REQUEST with proposed Service Priority, but having Num > > Addresses > > > set to zero? > > > > > > Is this intended? I.e., is the client allowed to request data, > > but not > > > propose IP address? If so, perhaps add sentence to Num Addresses > > > explaining that it can be 0 for CFG_REQUEST when no specific > > address > > > is request, but other parameters are requested. > > > > Hm... I think my co-authors can comment on this. > > > > [Med] This is intended. The requestor can suggest any of the > parameters in a request. That is already covered by the following: > > * " 0 if the Configuration payload has types CFG_REQUEST (if no > * specific DNS resolver is requested) ..." > * "If the initiator does not want to request specific DNS resolvers, > * it sets the Length field to 0 ..." > * "For a given attribute type, the initiator MAY send either an > * empty attribute or a list of distinct suggested resolvers." This is different case. I.e., there are (possibly) 3 different formats of CFG_REQUEST: CP(CFG_REQUEST) = ENCDNS_IP6() i.e., length = 0, initiator just request responder to send us informationfor ENCDNS_IP6. CP(CFG_REQUEST) = ENCDNS_IP6(Service Priority = 0, Num Addresses = 0, ADN Length = 16, IP addresses = (), Authentication Domain Name = "doh1.example.com", Service Paramters = "???") i.e., initiator requesting the responder to return information for Authentication Domain Name of doh1.example.com, and not providing priority or address of it, but perhaps including some service parameters it want the that server to have. CP(CFG_REQUEST) = ENCDNS_IP6(23, 1, 16, (2001:DB8:99:88:77:66:55:44), "doh1.example.com", "???") initiator requesting the responder for specific information, most likely something that it got last time, and initiator proposes it to the responder, in case it is still valid, and responder can send that same information back if it is valid, or return something else. Btw, for the second use case where the initiator fills in some of the information about the server it wants to talk to, it would be usefull to allow Service Priority to be 0, and explictly mention that this is not AliasMode, this is meaning that initiator does not care about the exact priority or does not know the priority, so it used 0 as placeholder. > > > In IP Address(es) explictly mention that it is field contain 4 > > octet > > > IPv4 addresses, or 16 octet IPv6 address without any delimeters > > etc. > > > This can be derived from the calculation of the length field, > > but I > > > think it should be mentioned here, even when it is obvious. > > > > OK. > > [Med] Actually, no. We don't have a mix. The AF is determined by the > attribute type. This is why we have the following: "One or more IPv4 > (for ENCDNS_IP4) or IPv6 (for ENCDNS_IP6)." Yes, I know, but it does not say how those IP-addresses are encoded in that field. They could be sent out as 16-octet values for both IPv4 and IPv6 addresses, where the IPv4 address would only use last 4 octets :-) Only way to know that this is not true is to check the formula in Length calculation... It is obvious that they are encoded as 4 octets for each IPv4 address and there is nothing between them, and same for IPv6 addresses, except each address takes 16 octets, but I think it would be good to explain it here. Something like this: For ENCDNS_IP4 this field contains one or more 4 octet IPv4 address, and for ENCDNS_IP6 this field contains one or more 16 octet IPv6 address. Address in this field can be used to reach ... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike
Valery Smyslov writes: > > In section 3.2 it is not clear what the length of the Hash Algorithm > > Identifiers fields is. It contains list of hash algorithms or one hash > > algorithm if this is response, but it is not clear what is response. > > What was meant is that a list of hashes is sent by a client (in > CFG_REQUEST) and a single hash is sent by a server (in CFG_REPLY). Yes, and I think it is easier to understand if we have two figures, one for the CFG_REQUEST and another for CFG_REPLY/CFG_SET. > > We have CFG_REQUEST, CFG_REPLY, CFG_SET, and CFG_ACK. Most likely > > CFG_REPLY and CFG_ACK are sent in IKE exchange response. On the other > > hand CFG_SET is usually used to set the parameters, thus the > > Certificate Digest would be required there. > > True, but IKEv2 doesn't currently use CFG_SET/CFG_ACK and > it explicitly allows implementations to ignore them. True, but you do include some text in some places about the CFG_ACK for example, so for completeness it would be good to define them in same way than RFC7296 does. I.e., CFG_SET is same as CFG_REPLY, and CFG_ACK is always empty (i.e., length = 0, and no other fields after that). > > 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >+-+-+---+ > >|R| Attribute Type |Length | > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 4: ENCDNS_DIGEST_INFO Attribute Format for CFG_ACK. > > > > and then explain the Hash Algorithm Identifier and List of Hash > > Algorithm Identifiers separately. > > We may do this for completeness, but as I've already mentioned > CFG_SET/CFG_ACK are not currently used in IKEv2. So I'm in not sure > if this is really needed and won't further confuse implementers... I think first two ones are needed, the last one can be left out and simply say in length definition that it is zero for CFG_ACK, just like you do for ENCDNS_IP*. > > Actually is there any point of having ADN Length and Authenticated > > Domain Name in CFG_REQUESTS ever? Why would someone calculate hashes > > with certain domain names with different hash algorithms? Perhaps we > > should define the format for CFG_REQUEST as follows: > > > > > > 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >+-+-+---+ > >|R| Attribute Type |Length | > >+---+---+ > >~ List of Hash Algorithm Identifiers ~ > >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 3: ENCDNS_DIGEST_INFO Attribute Format for CFG_REQUEST > > I'm confused, since CFG_REQUEST doesn't include Digest. > Am I missing your point? Thats the point. As the CFG_REQUEST does not include Certificate Digest, it only includes list of hash algorithms, there is no point of having Authentication Domain Name there either. So the ADN Length of CFG_REQUEST will always be zero, and Authentication Domain Name is omitted, but then we could simply omit the RESERVED and ADN Length fields also for more optimal encoding. I.e., if as we already have different format for CFG_REQUEST and CFG_REPLY/CFG_SET then making them even more different does not matter. If we want to keep the format same for all CFG_* then we need to format this payload as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+---+ |R| Attribute Type |Length | +-+-+---+---+ |RESERVED | Num Hash Algs | ADN Length | +---+---+ ~ Authentication Domain Name ~ +---+ ~ Hash Algorithm Identifiers ~ +---+ ~ Certificate Digest~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where for CFG_REQUEST the Num Hash Algs tells how many hash algorithms there are in the Hash Algorithm Identifiers list, and ADN Length will be zero, and Authentication Domain Name and Certificate Digest are omitted. For CFG_REPLY/CFG_SET the Num Hash Algs MUST be one, and Hash Algoritms Identifiers includes exactly one hash algorithm identifier which is used to calculate the Certificate Digest. With this payload format the decoder for this
[IPsec] Shepherd review of the draft-ietf-ipsecme-add-ike
Here are some my review comments while reading draft-ietf-ipsecme-add-ike: -- The text in section 3.1 should say that if length is 0, then no Service Priority, Num Addresses etc fields are present. I.e., add text in first bullet under Length saying that if length is zero, then later fields are not present. -- Also the text in Num Addresses indicate that it would be valid to send CFG_REQUEST with proposed Service Priority, but having Num Addresses set to zero? Is this intended? I.e., is the client allowed to request data, but not propose IP address? If so, perhaps add sentence to Num Addresses explaining that it can be 0 for CFG_REQUEST when no specific address is request, but other parameters are requested. -- In IP Address(es) explictly mention that it is field contain 4 octet IPv4 addresses, or 16 octet IPv6 address without any delimeters etc. This can be derived from the calculation of the length field, but I think it should be mentioned here, even when it is obvious. -- In section 3.2 it is not clear what the length of the Hash Algorithm Identifiers fields is. It contains list of hash algorithms or one hash algorithm if this is response, but it is not clear what is response. We have CFG_REQUEST, CFG_REPLY, CFG_SET, and CFG_ACK. Most likely CFG_REPLY and CFG_ACK are sent in IKE exchange response. On the other hand CFG_SET is usually used to set the parameters, thus the Certificate Digest would be required there. I would assume that there is only one Hash Algorithm Identifier for CFG_REPLY and CFG_SET, and then the Certificate Digest field is present. For CFG_REQUEST the Hash Algorithm Identifier is a list of two octet hash algorithm identifiers and the Certificate field is omitted. For the CFG_ACK only first 4 octets are included and Length is set to zero. I think it would be better to split the Figure 2 to three different figures: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+---+ |R| Attribute Type |Length | +-+-+---+---+ |RESERVED | ADN Length | +---+---+ ~ Authentication Domain Name ~ +---+ ~ Hash Algorithm Identifier (2 octets) ~ +---+ ~ Certificate Digest~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: ENCDNS_DIGEST_INFO Attribute Format for CFG_REPLY and CFG_SET 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+---+ |R| Attribute Type |Length | +-+-+---+---+ |RESERVED | ADN Length | +---+---+ ~ Authentication Domain Name ~ +---+ ~ List of Hash Algorithm Identifiers ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: ENCDNS_DIGEST_INFO Attribute Format for CFG_REQUEST 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+---+ |R| Attribute Type |Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: ENCDNS_DIGEST_INFO Attribute Format for CFG_ACK. and then explain the Hash Algorithm Identifier and List of Hash Algorithm Identifiers separately. Actually is there any point of having ADN Length and Authenticated Domain Name in CFG_REQUESTS ever? Why would someone calculate hashes with certain domain names with different hash algorithms? Perhaps we should define the format for CFG_REQUEST as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+---+ |R| Attribute Type |Length | +---+---+ ~ List of Hash Algorithm Identifiers ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Re: [IPsec] [saag] IETF 114 IPsecME report
Paul Wouters writes: > On Fri, Sep 23, 2022 at 1:15 PM Paul Wouters wrote: > > On Mon, Jul 25, 2022 at 10:24 PM Tero Kivinen wrote: > > Labeled IPsec is ready for publication and > will be submitted to the IESG immediately after this IETF. > > This has still not happened. The Shepherd's write up looks done, so it > would be nice if you can push this to Roman. > > I said that 4 months ago :( > > Tero, please grab a coke zero and spend an hour to push this forward. Let's > not wait yet another IETF please. Sorry no coke zeros here, I only drink Pepsi-max at home :-) Anyways checking the document now, and first of question I have why it is standard track not experimental. The shepherd writeup says: As it is adding a Traffic Selector type, and updates the core IKEv2 specification in RFC 7296, the document is Standards Track. but even if it adds new traffic selector type, I do not really see any reason for it to be standard track it could be experimental. Also I am not sure it even updates RFC7296. It adds new traffic selector type, and adds new rules how that must be narrowed, but it does not affect any old implementations. Old implementations do not need to be changed because of this draft if they do not want to support this. Actually now when I am reading it I can see it provides all kind of incorrect updates to the RFC7296, that will BREAK old implementations. For example the section 1.2 A Traffic Selector payload (TS) is a set of one or more Traffic Selectors of the same or different TS_TYPEs, but MUST include at least one TS_TYPE of TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. and section 1.3 The negotiation of Traffic Selectors is specified in Section 2.9 of [RFC7296] and states that the TSi/TSr payloads MUST contain at least one Traffic Selector type. This document updates the text to mean that the TSi/TSr payloads MUST contain at least one Traffic Selector of type TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE, as other Traffic Selector types can be defined that are complimentary to these Traffic Selector Types and cannot be selected on their own without TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE. are wrong. The RFC 7296 says: Each TS payload contains one or more Traffic Selectors. Each Traffic Selector consists of an address range (IPv4 or IPv6), a port range, and an IP protocol ID. There is no mandatory text there, this is all just explaining what traffic selectors are. Implicitly there will be one traffic selector as the selectors are taken from the policy, and if we matched some policy then there must be something that we will fill in the Traffic Selectors, but even that is not required by RFC7296. The requirement that each "TSi/TSr payloads MUST contain at least one Traffic Selector of type TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE" is incorrect, and cannot be added to RFC7296 directly or in here. There is for example TS_FC_ADDR_RANGE, and it is completely valid to only include TS_FC_ADDR_RANGE types and no TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE selectors. The RFC4595 defines this TS_FC_ADDR_RANGE and it contains 24-bit addresses for Fibre Channel communications, and other fields which I assume can be narrowed using regular rules specified in the RFC7296 (as RFC4594 does not specify its own narrowing rules). Only the TS_SECLABEL selector defined in this document is "complimentary to these Traffic Selector Types and cannot be selected on their own without TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE." There can be other traffic selectors defined in the future which do not require TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE types at all, thus that kind of limitation cannot be done here. For example the IEEE Std 802.15.9 negotiating keys for the IEEE Std 802.15.4 does not use TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE at all, as there is no IP-addresses there. Currently it does not define its own TS_TYPEs, it simply says we use Childless Initiation of IKEv2, thus there will not be TS payloads, and it will derive pairwise key between the two devices using SK_d and nonces. In the future there might be need to actually specify addresses also, and then they would need to come in IETF and specify new TS_TYPE to be used there. This document should simply say that TS_SECLABEL MUST NOT be used alone. This document must not try to do incompatible change to the base RFC7296 which would make conforming implemntations non-conforming. So I do not think this document should update RFC7296 at all, so most of the section 3 is wrong. The first bullet in section 3 is wrong, and second is already allowed by RFC7296, there nothing that says there cannot be one more more other TS_TYPES, thus it is not needed. Section 3 should most likely say something like this: The TS_SECLABEL cannot be used alone as it does not specify traffic selectors com
[IPsec] Murray Kucherawy's No Objection on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with COMMENT)
Murray Kucherawy via Datatracker writes: > The document shepherd writeup says: > > -- > 15. Should any informative references be normative or vice-versa? > > Yes. > -- > > I'm assuming the shepherd just ran over the question too quickly. > But, if you really meant "Yes" here, what's the plan to fix it? No, the document did have incorrect split when I reviewed the document during the shepherd writeup, as can be seen from my email to authors: https://mailarchive.ietf.org/arch/msg/ipsec/eua5PlKQtlWA6Ni7PJRHukPbmsg/ but I still sent the document forward as this is something that can be fixed later, and did not want to delay publication while waiting the authors to fix these kind of issues. The authors published -06 version immediately after that which fixed the normative and informative references split: https://author-tools.ietf.org/iddiff?url1=draft-ietf-ipsecme-ikev1-algo-to-historic-05=draft-ietf-ipsecme-ikev1-algo-to-historic-06=--html -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG Adoption call of draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt
I started WG adoption call of this draft about month ago, and there has been several people supporting the adopting and publishing this document quickly. And as has not been any opposition to adopt this document, so the WG adoption call passes. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WG adoption call of the draft-pwouters-ipsecme-multi-sa-performance
I started WG adoption call of this draft about a month ago and while there were some opposition to adopt this draft, I think they were mostly because they thought this document does not go far enough and does not solve all the problems in this space. I think there was enough support for adopting this draft, and then in the working group we can discuss whether we want to extend the scope of the draft (and most likely delay the publication while that new text needs to be written and protocol designed), or whether we keep the current scope, and get it out quickly. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WGLC of draft-ietf-ipsecme-ikev2-auth-announce
I started this last call almost a month ago, and I have not seen any discussion, comments or emails on the ipsec list. For me that would indicate that nobody has actually reviewed the document during the WGLC, and would indicate there is very little interest in publishing this document. I will keep the document in WGLC state for some time, but perhaps we should think whether there is enough interest to work on this issue at all. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-08.txt
John Mattsson writes: > Not too late to change. According to NIST, 2048-bit MODP Group and 224-bit > Random ECP Group are MUST NOT use if the information you are protecting have a > lifetime longer than 8 years (2031 - today). 1024-bit MODP is two security > levels below that. I think IETF in generally way to slow if deprecating stuff. > I would love to see the following deprecated as well: I.e., if your information needs only to be protected for few months, those smaller groups should be ok... Also note, that IETF does not give recommendations of the policy of which algorithms users should be using. IETF is giving recommendations of which algorithms are in actual implemenations. If we deprecate some algorithms that means that the implementations will remove support for that algorithms at some point. I.e., then we are taking options away from users and they can't use them even if they would be completely suitable for them in their environment. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-08.txt
Paul Wouters writes: > ps. Re-reading this draft, does anyone remember why we deprecated DH22 > (1024-bit MODP Group with 160-bit Prime Order Subgroup) but not DH2 > (also 1024 bit MODP) >From 8247: ... Group 2 or the 1024-bit MODP Group has been downgraded from MUST- in RFC 4307 to SHOULD NOT. It is known to be weak against sufficiently funded attackers using commercially available mass-computing resources, so its security margin is considered too narrow. It is expected in the near future to be downgraded to MUST NOT. ... Groups 22, 23, and 24 are MODP groups with Prime Order Subgroups that are not safe primes. The seeds for these groups have not been publicly released, resulting in reduced trust in these groups. These groups were proposed as alternatives for groups 2 and 14 but never saw wide deployment. It has been shown that group 22 with 1024-bit MODP is too weak and academia have the resources to generate malicious values at this size. This has resulted in group 22 to be demoted to MUST NOT. Groups 23 and 24 have been demoted to SHOULD NOT and are expected to be further downgraded in the near future to MUST NOT. Since groups 23 and 24 have small subgroups, the checks specified in the first bullet point of Section 2.2 of "Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2)" [RFC6989] MUST be done when these groups are used. ... I.e., the main reason being that group 2 was only MUST algorithm before, and moving it from MUST to MUST NOT while we do not have any oher algorithms as MUST was considered bad. Also the group is formed inin a deterministic way which should not make it possible that the group is created to be weak from the beginning. There were no such concerns for the group 22, and also as there is no way of knowing whether that group is generated as weak group that is even more reason to make it MUST NOT. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPsecME WG Adoption call for draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt
This is two week working roup adoption call for he draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt. If you support adoption of this document to the IPsecME WG send email to the list before the 2022-11-24. Note, that this is starting point for the document, so if you have any comments send them to list also. This should be part of our charter section call us to work better on constrained networks: A growing number of use cases for constrained networks - but not limited to those networks - have shown interest in reducing ESP (resp. IKEv2) overhead by compressing ESP (resp IKEv2) fields. The WG will define extensions of ESP and IKEv2 to enable ESP header compression. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] IPsecME WG Adoption call for draft-pwouters-ipsecme-multi-sa-performance
This is two week working group adoption call for the draft-pwouters-ipsecme-multi-sa-performance. If you support adoption of this document to the IPsecME WG send email to the list before the 2022-11-24. Note, that this is starting point for the document, so if you have any comments send them to list also. There is no specific item for this in our charter, but this should (now) be small enough change to fit in the "minor extensions" category... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] WGLC for draft-ietf-ipsecme-ikev2-auth-announce starting
This will start the 2 week working group last call document for draft-ietf-ipsecme-ikev2-auth-announce. The working group last call will end at 2022-11-24. Please review the document and send comment to the list if you think it is ready for publication. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Datatracker related RFCs list
Some people have been asking that we add related RFCs to the IPsecME datatracker documents page. I did it now, I added most of those documents which are referenced from the IKEv2 IANA page. I did leave out mobile ip, and fibre channel documents. If anything is missing or there is RFCs that should not be there, send me email. Btw, authors who have individual drafts waiting to be published that are getting IANA allocations, I did not add those documents to the list yet, but send me an email when those are out as RFC, and I will add them too (i.e. the ghost etc ones). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] AD review of draft-moskowitz-ipsecme-ipseckey-eddsa-02
Robert Moskowitz writes: > > Value Description Format description Reference > > 0 No key is present[RFC4025] > > 1 A DSA Public Key [RFC2536] Section 2 [RFC4025] > > 2 A RSA Public Key [RFC3110] Section 2 [RFC4025] > > 3 An ECDSA Public Key [RFC6605] Section 4 [RFC4025] > > TBD1 An EdDSA Public Key [RFC8080] Section 3 [ThisRFC] > > > > Adding the section numbers would be useful, as those documents define > > both DNSKEY and RRSIG resource records, so pointing to one of them > > helps. > I like this second way. Does including the sec occur in any other > registries? We will have to ask IANA; it does make sense as you say in > this specific case. Yes. For example IKEv2 Transform Type 4 registry has section numbers for Recipient Tests: https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8 > We would need to get IANA signoff on this, IMO. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] [saag] AD review of draft-moskowitz-ipsecme-ipseckey-eddsa-02
Robert Moskowitz writes: > > Value Description > > > > 1A DSA Public Key is present, in the format defined in [RFC2536] > > 2A RSA Public Key is present, in the format defined in [RFC3110] > > 3An ECDSA Public Key is present, in the format defined in [RFC6605] > > I can remove the reference column? It seems this is always called for. > So either we accept the build errors that still result in a usable > draft, or we make these entries two lines like: How about we cut the "is present" text. I do not think it gives any useful information. I mean if there is key in format defined in some rfc in this RR, then yes, the key is present, we do not need to repeat that. 0No key is present 1A DSA Public Key in the format defined in [RFC2536] 2A RSA Public Key in the format defined in [RFC3110] 3An ECDSA Public Key in the format defined in [RFC6605] Or we could even split the reference and format in different columns: Value Description Format description Reference 0 No key is present[RFC4025] 1 A DSA Public Key [RFC2536] Section 2 [RFC4025] 2 A RSA Public Key [RFC3110] Section 2 [RFC4025] 3 An ECDSA Public Key [RFC6605] Section 4 [RFC4025] TBD1 An EdDSA Public Key [RFC8080] Section 3 [ThisRFC] Adding the section numbers would be useful, as those documents define both DNSKEY and RRSIG resource records, so pointing to one of them helps. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
to...@strayalpha.com writes: > > The normal case to do that is that IPsec SGW keeps track of the size > > of packets that are ok, and which are too big based on the information > > it receives. I.e., it might have received unsecured ICMP PTB message > > from the network for its own Child SA, but only knows the SPI of the > > Child SA, not who was the original sender. So it keeps track that for > > this SPI the ESP packets cannot be larger than xxx bytes. > > > > Next time it receives a packet from the source and when it is > > encrypting it, it will verify that it will fit the size set for that > > Child SA, and if it is too big, it will generate ICMP PTB for that > > specific packet. > > > > IPsec gateways have been doing that for years, and this has been > > described in the RFC4301 section 8.2.1. > > That would happen because the tunnel packet caused PTB. This case is > described in intarea-tunnels 4.3.2. The way in which IPsec gets it > wrong (IMO) is described in Section 4.3.1 and is related to RFC > 3884, e.g., by subsuming the functions of a router inside the IPsec > mechanism, rather than operating strictly as a tunnel, which should > be represented as a link - and *links do not send ICMP messages. > > What SHOULD happen in IPsec is that the SPI should have an MTU > (being a link) and the *router* where packets are forwarded into the > tunnel should determine when packets that want to enter that link > are too big - at which point, per RFC 1812, the *router* should be > sending the ICMP. This is what the RFC4301 describes if I understood your description correctly. I.e., when SGW A (IPsec security gateway routing clear text packets to encrypted tunnel) sends packets out having DF=1 and gets ICMP PTB back from the route, it does not know which packet triggered this event, as the ICMP PTB might not have enough data in it to identify that. It should get the SPI and destination address, so it should be able to associate that ICMP PTB to some Child SA. Now it will store that information to that Child SA, and wait for next packet to arrive, i.e., effectively setting the MTU of the link to whatever ICMP PTB said (and taking in to account the overhead caused by the IPsec). When packet that is too big for that tunnel it will generate ICMP PTB just like router should. The difference there is that this cannot happen on the first packet only for later packets. So I think IPsec is still doing everything correctly. This case is not about that it is when the incoming packets that does not have DF set, and in that case the router can fragment them before or after sending them to the tunnel. Quite typically they encrypt the whole packet, and then fragment the resulting ESP packets, as that makes it easier for the receiving end to the exit tunnel checks. If the incoming frame was 1500 bytes and we added around 50 bytes of IPsec overhead the resulting packet is 1550 bytes which gets fragment to one 1500 byte fragment and one 50 byte fragment. > > My understanding is that this draft (which I have not yet properly > > read) is solving the situation where the tunnel does not get ICMP PTB > > messages as they are forwarding packets with DF bit set to 0, and then > > the receiving end will see extra fragmentation happening for the > > packets. Then the receiving end will simulate the ICMP PTB by sending > > authenticated IKEv2 notification that tells the sending end that his > > packets got fragmented. > > The only reason the packet would have been too big at the receiver > is if it were to exceed the receiver’s reassembly buffer. That’s not > what’s happening here. Now if in the middle of the path there some other MTU in use, lets say there is another IPsec tunnel there (tunnel in tunnel), and that getway is fragmenting the incoming packet before sending it to the tunnel (it could fragment it before putting it to tunnel, as the packet was already fragmented so fragmenting it again does not matter, or perhaps there some link between it and its destination which does not support IP fragments). So it takes the 1500 byte fragment and refragments that to 1420 byte and 80 byte fragments, and adds IPsec overhead. Then when that tunnel is decapsulated away we have 3 fragments ending to the receiving node. One is 1420 bytes, another is 80, and the last one is 50 bytes. When the receiving SGW B will see this it most likely can know that this was not original SGW A actually used, thus could report back to the SGW A saying that SGW A should use MTU of 1420 bytes instead of 1500 when sending ESP packets over this route. This is not really a PTB event as everything still works regardless what SGW A and B do, but this is still not optimal behavior of the tunnels, and it would be useful to detect and fix this situation. > It seems like there’s confusion about the fact that the source can > somehow avoid fragmentation of the tunneled packets. That can’t > happen - see intarea-tunnels Sec 3.6.3. Source fragmentation can
Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review
to...@strayalpha.com writes: > In the best case scenario, the security gateway informs the source node to > reduce the size of the inner packet with an ICP PTB packet for example. > > How? It can’t send an ICMP because it doesn’t have *the* packet causing the > problem to “reflect” back to the source. The ingress may not know who the > source is (there may be thousands or millions of sources). So which source? The normal case to do that is that IPsec SGW keeps track of the size of packets that are ok, and which are too big based on the information it receives. I.e., it might have received unsecured ICMP PTB message from the network for its own Child SA, but only knows the SPI of the Child SA, not who was the original sender. So it keeps track that for this SPI the ESP packets cannot be larger than xxx bytes. Next time it receives a packet from the source and when it is encrypting it, it will verify that it will fit the size set for that Child SA, and if it is too big, it will generate ICMP PTB for that specific packet. IPsec gateways have been doing that for years, and this has been described in the RFC4301 section 8.2.1. My understanding is that this draft (which I have not yet properly read) is solving the situation where the tunnel does not get ICMP PTB messages as they are forwarding packets with DF bit set to 0, and then the receiving end will see extra fragmentation happening for the packets. Then the receiving end will simulate the ICMP PTB by sending authenticated IKEv2 notification that tells the sending end that his packets got fragmented. Now the sending end can do similar processing of this information that it does for unauthenticated ICMP PTB messages received for ESP packets. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance
Valery Smyslov writes: > > There is no point of one having for example 10 fast cpus sending > > traffic over 10 Child SA, when the receiving end only has two cpus > > which are about same than the other ends cpus. The receiving end will > > not be able to keep up with the traffic it is getting in, thus it will > > drop packets as it can't decrypt them fast enough. > > I'm not so sure. Consider the situation when one host a single HSMs > which is optimized for high-performance crypto operations, > while the other is a general purpose server with several tens of CPUs. > In this situation the HSM beats any CPU in performance, so if the > HSM can handle several SAs, it's beneficial to create as many SAs as > it can handle and distribute those SAs over CPUs on the other peer. Whether HSM is faster than CPU depends on so many matters, and I have seen so many cases where when new CPU architecture came out, then it was again faster to do crypto on the CPU than offload it to HSM as the interaction between the CPU and HSM was too slow. And then HSM was upgraded and it was again faster etc. I think they were always within order of magnitude of each other, i.e., HSM was maximally only 10 times faster than CPU. There usually was no need to do them faster than that as the line speeds used limited the speeds needed anyways. But my experience of them is more than 10 years old, so this might have changed lately. Question is how many CPUs do you need to saturate 100 Gbit/s network link compared to how many HSM CPUs you need? is there more than 10 times bigger number between them. Do you have any real world values for those? I.e., how fast can one modern cpu do crypto (just plain crypto, no ipsec etc), and how fast can some modern crypto hardware do the same? -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance
Paul Ponchon \(pponchon\) writes: > > > Using different real child SA’s was needed to ensure the > > > cryptographic security properties. > > Is this requirement only based on not reusing the same IV on different cores > or is there an additional factor I missed? IV space and replay counter are the problem. It is just so much easier to use different Child SAs per CPU and than trying to solve the IV space problem. On the G-IKEv2 we had to solve the splitting IV space to separate senders, and that causes all kind of issues, and we have to disable replay protection on those SAs. Getting replay protection working on the Child SA that is shared by multiple CPUs is much harder than creating separate Child SA for each CPU. > > This is something that is really a important. The keymat between the > > CPUs can't be same, but we could in theory create a new key hierarchy > > that generates keys for each sub Child SAs for each CPU, but I think > > that will just complicate things more, and having real Child SAs for > > each cpu is the correct solution. > > We're are currently facing some scalability issues with using > multiple Child SAs and we think it is possible to reuse the same > keymat on all the per cpu SAs. There must be something wrong in your implementation. There should be no scaling difference for each cpu in cases where there is one Child SA per cpu with different keymat than cases where there is one Child SA per cpu with same keymat than some other cpu has. Or more likely the problem is its much harder to scale to make them share keymat, as in that case each of the cpu needs to talk to all other cpus to make sure they do not reuse the replay counter, or IV space, and keep track of number of bytes transmitted etc. If your Child SA is local to your cpu all those issues are localized and there should not be any scaling issues. There will be scaling issues when generating those Child SA through IKEv2, but IKEv2 should be able to create hundreds of Child SAs per second when using proper window size and not doing PFS on the Child SAs. If you are not implementing proper window size on IKEv2 then you are limited to your RTT, i.e., if your RTT is 50 ms, then you can create dozen or so Child SA per second, as you need to wait each Child SA packet before you can start new one. All this is again not stable state scaling issue, all IKEv2 issues are issues that should not affect stable state at all. > For this to work and respect the uniqueness of the IV, some > mechanism would be needed. But that can be implemented without > per-packet locks for most ciphers (e.g., by splitting the IV space, > or making bulk IV allocations). And we would also ensure that the > keymat is used in a FIPS compliant manner. I remember when we had discussion of the Implicit IV (RFC8750) people were saying that it is not clear whether the IV generation must be inside the fips boundary or not, and if so we are not allowed to bring external data (sequence number) and generate IV from that as that would violate the FIPS boundaries, meaning the FIPS boundary would grow larger, and more of the implemenation needs to be FIPS certified, not just the actual crypto. If we are doing similar things here, same thing might happen, meaning suddenly we need to start FIPS certifying the actual bulk IV allocation process or something like that and that would mean much larger boundary for FIPS certification. > Would there be any other concerns in reusing the same keymat between > multiple SAs ? Not really, but I do not also see any reason why there would be a need to share KEYMAT between multiple SAs. If the issues in the IKEv2 Child SA generation are overwhelming then we can simply use the IKEv2 KEYMAT to create new per Child SA KEYMATs for each CPU in the cryptographically safe way (i.e., make IKEv2 extension to do that). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance
[Replying to this email, but commenting about the others also] Paul Wouters writes: > On Oct 21, 2022, at 03:37, Steffen Klassert > wrote: > > Another possibility would be to use the same keymat on all > > percpu SAs > > You cannot do that. You need to ensure unique IVs for AEAD so you > would need to subdivide the IV space. You would also still reach max > operations on these SAs on different times AND things like FIPS puts > an operational max count on the key usage which you can’t do if the > key is used by multiple different states. > > Using different real child SA’s was needed to ensure the > cryptographic security properties. This is something that is really a important. The keymat between the CPUs can't be same, but we could in theory create a new key hierarchy that generates keys for each sub Child SAs for each CPU, but I think that will just complicate things more, and having real Child SAs for each cpu is the correct solution. In your discussion you were talking about cases where one device has hundreds of cpus and other have few. Only case where such configurations would be useful when other has lots of really low powered cpus and other one has few very fast ones. My understanding is that this is not really happening. Usually the one that has more cpus has cpus which are about the same speed then the one having fewer cpus. There is no point of one having for example 10 fast cpus sending traffic over 10 Child SA, when the receiving end only has two cpus which are about same than the other ends cpus. The receiving end will not be able to keep up with the traffic it is getting in, thus it will drop packets as it can't decrypt them fast enough. So I think we should try to concentrate in the cases where the number of cpus for each end is in the same ballpark. We can have one host having 2 cpus that is twice as fast as the other host having 4 cpus, so creating 4 Child SAs is ok in that case, but I do not think there is ever cases where we are generating more than 2-4 SAs per cpu, i.e., if one end has 2 cpus then practical limit is 8 Child SAs. Any more than that will not help. Also host having hundreds of CPUs will most likely talk to hundreds of other hosts too, so using 10 of cpus to talk to one host, and 10 to talk to other host etc is also a way of splitting up the work. I.e. that "gateway" would most likely advertise having fewer CPUs it actually has. The other host having two cpus will most likely be the "client" end and only talk to that one "gateway" (or someone used way too much of money for device that does not need to be that big)... And I do agree on Valery that there is no point of trying to guess what kind of broken implementations there are out there, we should assume that implementations are following RFC7296, and if there are so many broken implementations we need to take them in to account, then we might want to update RFC7296 Talking about locking and such thing is bit distracting, as you can do lots of things without locking depending on the datastructures and who writes them and so on. This goes so low level that I am not sure it is that beneficial to talk about them here. For example there are ways of updating the per cpu SAD without locks provided there is only one entity that can update them... We should make sure that all the stable state processing can be done efficiently i.e., without locking etc, but IKE SA creation etc happens every few hours etc, and trying to optimize locking behivior of them is not that useful in the big picture. Also I think it is just better to create all Child SAs at the beginning, i.e., no point of doing that much per CPU aquiring etc. I mean you have some way of distributing packets going out to CPUs before that and if that is round robin then you will create all per CPU SAs very quickly, and if that is something else (like this TCP stream is locked to this CPU), then you mostly keep using only that one CPU (in which case per cpu aquire will be useful), but all of these depends so much on the implementation we are not talking about here that I think that should be left to implementations to decide. If we use per cpu aquiring things then other end might need to create Child SAs too, just in case if the one inititing the connection only sent out one packet and create one SA, and then the other end would like to have 8 SAs for its 8 cpus, but only one was created, so would it now create 7 missing one, or wait for the other end to create them etc. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-multiple-ke-06
Roman Danyliw writes: > ** Section 3.2.4. > > The responder MUST handle this >situation gracefully and delete the associated state if it does not >receive the next expected IKE_FOLLOWUP_KE request after some >reasonable period of time. > > Is there a guidance on the timeout value? > > IKEv2 traditionally does not mandate exact timeouts. For example, the same > situation happens if the initiator completes IKE_SA_INIT and never starts > IKE_AUTH. The responder should eventually delete the incomplete IKE SA, but > RFC 7296 does not specify how long the waiting time is. > > FWIW, our implementations waits 5 seconds by default (which is adjustable > value). > > Do you think we should recommend (but not mandate) to wait for 5-10 seconds? > > [Roman] A recommended value would help if you are comfortable giving it, or > explaining why it’s hard to give one. This is a common question that comes > from transport review during IETC LC or IESG review. Suitable values can be between few seconds up to few minutes. For example timeout between IKE_SA_INIT and IKE_AUTH might require user interaction, thus it might be up to minutes if PIN code to unlock user auth device is required etc. Because the timeouts are so different depending on the environment and usage scenario we do not give them in the IKEv2 document. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Murray Kucherawy's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)
Murray S. Kucherawy writes: > This posture worries me. I've no doubt that you're doing a fine job as the DE > for the registries for which you're responsible, probably because you were > around during IPSec's development. But what about your successor(s)? Will > they have all of the context, background, and vision you have in order to > continue where you eventually leave off? Designated experts are called experts, not automation robots following steps set in RFCs. My understanding has been that the reason we use experts is that then we do not need to give them exact rules to follow. Some of the RFCs gives so strict rules for experts to follow, that there really is no point of having expert involved at all, IANA could simply follow those same steps themselves. We currently have two experts for the IPsec registries (another one was added few years back). Also I would assume there is pool of about 5-10 people in the IETF that could easily work as an expert on the IPsec registries on the short notice (whether they would be willing or having time is another issue :-) On the other hand IPsec registries are easy, as we do have active group of people still working on it, meaning we have active mailing list and in case there are issues where experts are unsure, the experts can go and verify the decisions on the mail list. > The IETF, I'm coming to believe, has generally not done a good > enough job of succession planning. This is one place where we can > shore up that problem. > > I'll clear my DISCUSS, but I urge the working group and sponsoring > AD to give this some more thought. We currently have two experts for IPsec related IANA registries, so we have already given this some thought... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Murray Kucherawy's Discuss on draft-ietf-ipsecme-iptfs-17: (with DISCUSS and COMMENT)
Murray Kucherawy via Datatracker writes: > -- > DISCUSS: > -- > > Section 7.1 creates an IANA registry with "Expert Review" rules. Of such a > registry, Section 4.5 of RFC 8126 says, among other things: > >The required documentation and review criteria, giving clear guidance >to the designated expert, should be provided when defining the >registry. > > This document doesn't do so. Is that guidance available somewhere else, or > should some be added here? This is common in the IPsec documents. The working group has assumed that experts are experts and they know what to do without being explictly instructed to do so As an IANA Expert for most of the IPsec related registries, I hope that I have been able to do that job in a such way that other people have found that good enough (at least I have not heard complains about that). For example the IKEv2 registries created in RFC4306 (https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml) are all expert review and the RFC4306 gave following instructions: -- 6. IANA Considerations This document defines a number of new field types and values where future assignments will be managed by the IANA. The following registries have been created by the IANA: IKEv2 Exchange Types (section 3.1) IKEv2 Payload Types (section 3.2) IKEv2 Transform Types (section 3.3.2) IKEv2 Transform Attribute Types (section 3.3.2) IKEv2 Encryption Transform IDs (section 3.3.2) IKEv2 Pseudo-random Function Transform IDs (section 3.3.2) IKEv2 Integrity Algorithm Transform IDs (section 3.3.2) IKEv2 Diffie-Hellman Transform IDs (section 3.3.2) IKEv2 Identification Payload ID Types (section 3.5) IKEv2 Certificate Encodings (section 3.6) IKEv2 Authentication Method (section 3.8) IKEv2 Notify Message Types (section 3.10.1) IKEv2 Notification IPCOMP Transform IDs (section 3.10.1) IKEv2 Security Protocol Identifiers (section 3.3.1) IKEv2 Traffic Selector Types (section 3.13.1) IKEv2 Configuration Payload CFG Types (section 3.15) IKEv2 Configuration Payload Attribute Types (section 3.15.1) Note: When creating a new Transform Type, a new registry for it must be created. Changes and additions to any of those registries are by expert review. -- (i.e., that is full IANA considerations section). -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Erik Kline writes: > > > > > I.e., either this document needs to formally update RFC 4303 by allowing > any > > number or another IP protocol number must be requested to the IANA. > > As I pointed out in my previous email that is not the case. > > The RFC4303 ESP has a Next Header field which contains indicates what > type of packet is inside the ESP packet. It typically contains IP > Protocol Numbers, but not always. Thats why the RFC4303 above says > "chosen from the set of IP Protocol Numbers". > > I disagree. 4303 S2.6 is very clearly talking about the Protocol Numbers > registry (the example of "41 means IPv6" is one of the things that give it > away). Note that IP Protocol value 41 for ESP does NOT MEAN same thing than what is described in the RFC 2473. The payload format of the ESP is different than what is described in that RFC. ESP Tunnel mode adds other pieces to the packet in different locations. The reason 41 (and 4) where chosen to match the ESP Tunnel mode is because they do have similar use than ESP Tunnel mode, but the actual protocols are different. > I think this document needs to request a protocol number from IANA. That would be one option, but then there might be issues where someone actually tries to use this outside the ESP, and because the current specification requires things to be negotiated in the IKEv2, this is not really possible, and using this outside ESP will also break the traffic flow confidentiality completely as there is no encryption of the traffic. We could also say that if the USE_AGGFRAG is negotiated for the Child SA (ESP SA) then Next header field is ignored on recipient, and sent as zeros, and all packets inside the Child SA are going to use AGGFRAG_PAYLOAD format. We do loose some information that would be helpful when debugging configuration issues, but the protocol would still work. It would also made it harder to do future enhancements to this protocol. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-iptfs-14: (with DISCUSS and COMMENT)
Éric Vyncke via Datatracker writes: > ## DISCUSS > > As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a > DISCUSS ballot is a request to have a discussion on the following topics: > > ### Section 6.1 > > ``` >An AGGFRAG payload is identified by the ESP Next Header value >AGGFRAG_PAYLOAD which has the value 0x5. The value 5 was chosen to >not conflict with other used values. The first octet of this payload >indicates the format of the remaining payload data. > ``` > This is in direct conflict with RFC 4303 (see below) IMHO as 5 is already > allocated to ST (RFC 1819, which is still 'current' even if it was never > used). > > But ESP RFC 4303 section 2.6 says that this is an IP protocol number (and 5 is > already allocated by the IANA): ``` >The Next Header is a mandatory, 8-bit field that identifies the type >of data contained in the Payload Data field, e.g., an IPv4 or IPv6 >packet, or a next layer header and data. The value of this field is >chosen from the set of IP Protocol Numbers defined on the web page of >the IANA, e.g., a value of 4 indicates IPv4, a value of 41 indicates >IPv6, and a value of 6 indicates TCP. > ``` > > I.e., either this document needs to formally update RFC 4303 by allowing any > number or another IP protocol number must be requested to the IANA. As I pointed out in my previous email that is not the case. The RFC4303 ESP has a Next Header field which contains indicates what type of packet is inside the ESP packet. It typically contains IP Protocol Numbers, but not always. Thats why the RFC4303 above says "chosen from the set of IP Protocol Numbers". The next paragraph in RFC4303 actually reuses one of the IP Protocol Number, i.e., 59 which means "no next header" for traffic flow confidentiality, i.e., for dummy packets: To facilitate the rapid generation and discarding of the padding traffic in support of traffic flow confidentiality (see Section 2.4), the protocol value 59 (which means "no next header") MUST be used to designate a "dummy" packet. Actually only case where the Next Header values actually may match the IP Protocol Numbers is when transport mode is used, and even then they negotiated in the IKEv2, i.e., ESP does not care really what next header number means, it just passes them through along with the packet itself. If IKEv2 negotiates transport mode IPsec SA using ESP for IP Protocol number 233 (which is unassigned), then policy matching of the kernel will somehow find those packets matching that unknown IP Protocol Number and pass them to ESP, and ESP will simply store the IP Protocol Number in its header and encapsulate the packet without looking in to it. There are some special / magical numbers used in the ESP. One of them is 59, another is 4 for IPv4 tunnel mode and one is 41 for IPv6 tunnel mode. Note, that both IPv4 (4) and IPv6 tunnel (41) mode Next Header field values are also special cases which do not exactly match the IP Protocol Numbers. The tunnel mode processing is completely different from transport mode processing, and contains additional things like exit tunnel checks etc. They are even negotiated in the IKEv2 in completely different manner than transport mode protocol numbers. I.e., in IKEv2 when negotiating tunnel mode the fact it is going to be tunnel mode is negotiated separately and the protocol number in the traffic selectors will indicate what protocol numbers are passed inside the tunnel, i.e., what is going to be the IP protocol number of the inner packet, not what is going to be in the Next Header field of the ESP. The Next Header field of the tunnel mode ESP is taken by checking whether packet is IPv4 or IPv6 and mapping that to the IP Protocol Numbers having little bit same name or meaning, but reading those RFCs related to those IP Protocol Numbers will simply confuse you if you try to implement tunnel mode IPsec. So the Next Header field can only match the IP Protocol numbers for transport mode ESP. There is no IANA registry for the Next Header fields of the ESP. As the number of special cases for Next Header fields is raising it might be beneficial to generate one at one point, but currently there is no IANA Registry for it. Also as the use of IPTFS is negotiated in the IKEv2, so unless both peers agree to use it, Next Header value of 5 is never used. The reason why we need something there is that in some cases it might be beneficial for debugging etc purposes to know the inner packet type, just like in the IPv4 and IPv6 tunnel mode. The ESP could have been written so that IPv4 and IPv6 tunnel mode would use exactly one Next Header value, and after the ESP takes the inner packet from then outer packet, it could check out the IP header to see whether it is IPv4 or IPv6 packet and process it based on that. I also do not think that this updates to the RFC4303 in any way. This is extension that is negotiated in the IKEv2, and only
Re: [IPsec] Fwd: New Version Notification for draft-moskowitz-ipsecme-ipseckey-eddsa-01.txt
Robert Moskowitz writes: > So I think the correct example should be: > > foo.example.com IN IPSECKEY > (10 0 4 . 3WTXgUvpn1RlCXnm80gGY2LZ/ErUUEZtZ33IDi8yfhM= ) > > I will fix my example. Do you think I should have both examples: with and > without gateway? More examples is usually better as long as they are correct :-) > Current IANA registry is: > > 0 No key is present [RFC4025] > 1 A DSA key is present, in the format defined in [RFC2536] [RFC4025] > 2 A RSA key is present, in the format defined in [RFC3110] [RFC4025] > 3 An ECDSA key is present, in the format defined in [RFC6605] > [RFC8005] > > Per Paul's request I am coming up that for EdDSA I would ask the following be > added: > > 4 An EdDSA Public key is present, in the format defined in [RFC8080] > [This] > > Note the addition of "Public" > > • So should 1 - 3 also have "Public" added? > • Should 4 NOT have "Public" > • Should text be added describing this registry to be for "Public" keys? The current wording is bit funny, but I think that it is talking about the host properties. I.e. the host having this IPSECKEY RR do have DSA key (both public and private keys), and the public key of that DSA key is given inside the IPSECKEY RR in format defined in RFC2536. Perhaps the best wording would be 3 An ECDSA Public key in the format defined in [RFC6605] Whether we want to change the other entries to match is then separate issue, and as this registry is IETF Review, I think we need and draft or similar to change the wording. I.e., if we want to change the wording of other entries, then we could request that change in this document too. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
