Re: [IPsec] Does I-D of extension of IPComp belongs to IPSec? FW: I-D Action: draft-ls-ipsecme-ipcomp-exclude-transport-layer-00.txt
L > On Mar 21, 2024, at 14:44, Tero Kivinen wrote: > > 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 seems not? I guess you are using ipcomp elsewhere ? I know for Linux the ipcomp code lives in the XFRM (aka IPsec) code, although perhaps hooks can be used outside of IPsec transforms. > 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, It is supported in Linux (and IKEv1 and IKEv2 daemons). I think the kernel supports multiple compression algs but some ike daemons only support using deflate but also encourage people away from using ipcomp at all. >> I am on site at Brisbane. It would be much appreciated if you have >> some time for a quick F2F discussion. >> >> Thanks, >> Hang Happy to talk - find the guy with yellow shoes. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[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
Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt
Panwei (William) wrote:
> Hi Michael,
>> > At yesterday's meeting, I think people basically understood and >
>> accepted the problem statement itself, but also raised different >
>> ideas regarding to the solutions. We'll try to do more analysis > and
>> comparison of possible solutions, including what you > suggested.
>>
>> I think that one thing that is unclear to me is whether the different
>> RANs can tolerate that all the different traffic share the same *IKE*
>> SA.
wei> [Wei (William) Pan] We did consider this before. Sharing the same IKE
wei> SA can partly release the pain, but not much. Assuming there are N
The reason I ask is if you can *NOT* share the IKE SA, then one solution is
to just give each base station a bunch of IP addresses. N of them.
Given RFC1918 this might be limiting. Given IPv6, a /64 per base station is
plenty. The advantage of that is that rather than having a VPNID, one has a
source/destination pair per RAN.
How are the base stations connected? Is it ethernet to the basestation?
Or do the base stations have direct fiber connections to each other? What
does the physical connectivity look like? I also wonder if there is a
metro-ethernet occuring, if the full mesh isn't overkill because the
metro-ethernet has other topological issues. {This question is mostly just
for my full understanding}
wei> the base station is deployed in a crowded area. We got from the
wei> customers that they want to double the number of operators sharing the
wei> RAN. Therefore, this solution isn't scalable enough for this need and
wei> future expansion.
What is the order of magnitude of N and M today?
2^4? 2^8? 2^16?
When you double, what is the starting order?
>> The next level is whether or not they can tolerate being in the same
>> CHILD SA. We could put the "VPN ID" at another layer (inside the
>> common tunnel), such as some kind of L3VPN, GRE, VXLAN.
wei> [Wei (William) Pan] Do you mean first encapsulating the original
wei> traffic into a tunnel that can carry the VPN info and then
wei> encapsulating the tunneled traffic into the IPsec tunnel? My initial
wei> feeling is that there may be operational and maintenance
wei> difficulties. We can have more thinking on this and reply later.
Yes, if you can tolerate the CHILD SA traffic being shared between all the
RANs, then having a new layer would let you scale without concern for IPsec.
You didn't answer that question: can they tolerate this?
Also, I think that this traffic is control plane traffic that allows for the
mobility of the devices attached to these base stations. I don't know the
3GPP protocol names for that.
But, does it also include encapsulated end-customer traffic?
I would assume that each base station has an SA to connect it to each of the
RAN's concentrators. L2TP or something like that.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
___
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 #1361634] expert review for draft-ietf-ipsecme-multi-sa-performance (ikev2-parameters)
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/ Unless you ask us to wait for the other reviewer, we’ll act on the first response we receive. With thanks, David Dong IANA Services Sr. Specialist ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt
Hi Michael, > > At yesterday's meeting, I think people basically understood and > > accepted the problem statement itself, but also raised different > > ideas regarding to the solutions. We'll try to do more analysis > > and comparison of possible solutions, including what you > > suggested. > > I think that one thing that is unclear to me is whether the different RANs > can tolerate that all the different traffic share the same *IKE* SA. [Wei (William) Pan] We did consider this before. Sharing the same IKE SA can partly release the pain, but not much. Assuming there are N peer devices and M operators sharing the RAN, currently, at least (2* N * M) SAs are needed: (N * M) IKE SAs and at least (N * M) Child SAs. Sharing the same IKE SA will still need at least (N * M) Child SAs. In our evaluation based on today's actual scenarios, the Child SAs needed will still be going to reach the base station's capacity if the base station is deployed in a crowded area. We got from the customers that they want to double the number of operators sharing the RAN. Therefore, this solution isn't scalable enough for this need and future expansion. > The next level is whether or not they can tolerate being in the same > CHILD SA. We could put the "VPN ID" at another layer (inside the > common tunnel), such as some kind of L3VPN, GRE, VXLAN. [Wei (William) Pan] Do you mean first encapsulating the original traffic into a tunnel that can carry the VPN info and then encapsulating the tunneled traffic into the IPsec tunnel? My initial feeling is that there may be operational and maintenance difficulties. We can have more thinking on this and reply later. > > we'd like to know more if it's OK. Switching to a new protocol is > > still a reasonable solution for us, although it has pains. > > Developing a new protocol in IETF will cost time, we'd like to > > adopt the new protocol after it's standardized. But we need to > > solve our problem > > I don't think you need any new protocols, but maybe new ways to > combine existing protocols. For instance, some IKEv2 support for > configuring VXLAN. > But, this depends upon the *security* and traffic isolation that you need. > For instance, do you have issues of traffic accounting between the RANs > that occurs on the outside (ESP) packets. [Wei (William) Pan] Thanks for your feedback, we will put it into consideration. This is why we think we need to do the analysis and comparison of solutions, to find out what is the most possible and reasonable solution. Regards & Thanks！ Wei PAN (潘伟) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] AD Review of draft-ietf-ipsecme-multi-sa-performance-05
All of these were resolved in -06 Paul Sent using a virtual keyboard on a phone > On Mar 20, 2024, at 15:33, Roman Danyliw wrote: > > Hi! > > Thanks for the quick response. Below is a bit more editorial back-and-forth > for small number of issues. All of the other discussion removed from the > thread made sense for the future -06 that can go to IETF LC. > >> -Original Message- >> From: Paul Wouters >> Sent: Wednesday, March 20, 2024 12:26 AM >> To: Roman Danyliw >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] AD Review of draft-ietf-ipsecme-multi-sa-performance-05 >> >> Warning: External Sender - do not click links or open attachments unless you >> recognize the sender and know the content is safe. >> >> >>> On Tue, 19 Mar 2024, Roman Danyliw wrote: >>> >>> I performed an AD review of draft-ietf-ipsecme-multi-sa-performance-05. I >> have a mostly editorial feedback below: >>> > > [snip] > >> And answering that: >> >>Most IPsec implementations are currently limited to using one >>hardware queue or a single CPU resource for a Child SA. Paralyzing >>the packet encryption can be done, but there is a bottleneck of >>different parts of the hardware locking or waiting to get their >>sequence number assigned for the packet it is enrypting. The >>result is that a machine with many such resources is limited to >>only using one of these resources per Child SA. This severely >>limits the throughput that can be attained. For example, at the >>time of writing, an unencrypted link of 10Gbps or more is commonly >>reduced to 2-5Gbps when IPsec is used to encrypt the link using >>AES-GCM. By using the implementation specified in this document, >>aggregate throughput increased from 5Gbps using 1 CPU to 40-60 >>Gbps using 25-30 CPUs. > > Maybe s/Paralyzing the packet encryption/Running packet steam encryption in > parallel/ > > Also. s/enrypting/encrypting/. > > Otherwise, LGTM. > > [snip] > >>> ** Section 4. Is this section normative? Why are RFC2119 key words used in >> an example? >> >> Why do you say this is an example? It is the Implementation Considerations >> section telling you to do or do not some things? > > ==[ snip ]== > There are various considerations that an implementation can use to > determine the best way to install multiple Child SAs. Below are > examples of such strategies. > ==[ snip ]== > > I inferred this text to be non-normative and only examples because the second > sentence said these were "examples". Maybe just drop that second sentence to > eliminate confusion? > >>> ** Section 6. >>> Peers SHOULD be lenient with the maximum number of Child SAs they >>> allow for a given TSi/TSr combination to account for corner cases. >>> >>> What does “lenient” mean here? >> >> "account for corner cases" as explained further done? >> >> Eg one should not use a hard max of 4 when one runs on a 4-CPU system. > > Consider if "flexible" is what you want here instead. > > Roman > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt
Panwei \(William\) wrote: > At yesterday's meeting, I think people basically understood and > accepted the problem statement itself, but also raised different ideas > regarding to the solutions. We'll try to do more analysis and > comparison of possible solutions, including what you suggested. I think that one thing that is unclear to me is whether the different RANs can tolerate that all the different traffic share the same *IKE* SA. The next level is whether or not they can tolerate being in the same CHILD SA. We could put the "VPN ID" at another layer (inside the common tunnel), such as some kind of L3VPN, GRE, VXLAN. > we'd like to know more if it's OK. Switching to a new protocol is > still a reasonable solution for us, although it has pains. Developing > a new protocol in IETF will cost time, we'd like to adopt the new > protocol after it's standardized. But we need to solve our problem I don't think you need any new protocols, but maybe new ways to combine existing protocols. For instance, some IKEv2 support for configuring VXLAN. But, this depends upon the *security* and traffic isolation that you need. For instance, do you have issues of traffic accounting between the RANs that occurs on the outside (ESP) packets. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt
Hi Steffen, Thanks for your input and that is very useful for us. At yesterday's meeting, I think people basically understood and accepted the problem statement itself, but also raised different ideas regarding to the solutions. We'll try to do more analysis and comparison of possible solutions, including what you suggested. What you are doing (new version of WESP) is also interesting to us, we'd like to know more if it's OK. Switching to a new protocol is still a reasonable solution for us, although it has pains. Developing a new protocol in IETF will cost time, we'd like to adopt the new protocol after it's standardized. But we need to solve our problem now, and therefore, it's better for us to consider some forward compatible things in advance. For example, do you think it's better to encrypt the "Flow Identifier" field or not? Regards & Thanks！ Wei PAN (潘伟) > -Original Message- > From: Steffen Klassert > Sent: Friday, March 15, 2024 5:31 PM > To: Paul Wouters > Cc: Panwei (William) ; ipsec@ietf.org WG > > Subject: Re: [IPsec] I-D Action: > draft-he-ipsecme-vpn-shared-ipsecsa-00.txt > > On Mon, Mar 11, 2024 at 11:36:03AM -0400, Paul Wouters wrote: > > On Mon, 11 Mar 2024, Panwei (William) wrote: > > > > > Indeed, splitting the 32-bit SPI into two sub-fields, the VPN ID > sub-field and SPI sub-field, may also be one option. This solution doesn't > need to change the ESP packet format, but it also has some > disadvantages. > > > The first one is the scalable issue. 256 VPN IDs may be enough for > use for current RAN Sharing scenario, but when considering the service > slicing feature, thousands and even more VPNs will be needed in the > future. So, it's better to assign 16 bits to the VPN ID sub-field. Therefore, > the SPI sub-field will be trenched to 16 bits, which means the available > SPIs are 64k. This can have a negative impact on the expansion of usable > scenarios in the future. > > > The second problem is the high possibility of packet disorder. > Although all VPNs share one actual SA and the sender assigns sequence > numbers in sequence to all the traffic no matter which VPN they belong > to, different VPNs will use different SPIs in the ESP packets. This will > interfere with the load balance process of the on-path routers because > they usually look at the SPI field when doing the hash. This may lead to > packet disorder at the IPsec receiver. > > > Therefore, we currently still prefer a separate field representing the > VPN ID. But we are open to more discussions and future changes. > > > > Thanks, those arguments are clear. Perhaps Steffen can take these into > > consideration as well when thinking about ESPv4 / WESP :) > > The root cause what this draft tries to solve is that we need a possibility > to expose information of the inner packet flow to the outer packet. > Basically this is the same problem, the sequence number subspaces draft > tries to solve. So instead of solving the same problem for every single > usecase in a diffetent way, it would be nice to have a generic solution for > that problem. I'm thinking of some 'Flow Identiyer' field that can be used > for all this cases. > > The biggest problem here is that some usecases need to have this > information transparent to the outer network. For instance the sequence > number subspaces information is needed by the receiving NIC to do RSS > properly. For that reason negotiating the new field does not help. The NIC > can't know what you have negotiated, so the new field is useless in that > case. Unfortunately ESP does not have a version number, so we can't > change it in any transparent way. The only possibility for ESP is to use the > SPI because this is already used as the ESP 'Flow Identifyer'. > > At the last IETF meeting I proposed to use an updated WESP to do > changes that need to be transparent to the network. WESP has a version > numbers and can be adjusted in a transparent way. > I'm currently preparing a WESPv2 draft that I plan to publish after the > next IETF meeting. Some people here on the list have seen it already, > that's why Paul mentioned me in his mail. > > I know that switching to another protocol is always a pain, but I don't see > other options do do that right. > > Steffen ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Last Call: (IKEv2 support for per-resource Child SAs) to Proposed Standard
The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IKEv2 support for per-resource Child SAs' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2024-04-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines two Notify Message Type Payloads for the Internet Key Exchange Protocol Version 2 (IKEv2) to support the negotiation of multiple Child SAs with the same Traffic Selectors used on different resources, such as CPUs, to increase bandwidth of IPsec traffic between peers. The SA_RESOURCE_INFO notification is used to convey information that the negotiated Child SA and subsequent new Child SAs with the same Traffic Selectors are a logical group of Child SAs where most or all of the Child SAs are bound to a specific resource, such as a specific CPU. The TS_MAX_QUEUE notify conveys that the peer is unwilling to create more additional Child SAs for this particular negotiated Traffic Selector combination. Using multiple Child SAs with the same Traffic Selectors has the benefit that each resource holding the Child SA has its own Sequence Number Counter, ensuring that CPUs don't have to synchronize their cryptographic state or disable their packet replay protection. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-multi-sa-performance/ No IPR declarations have been submitted directly on this I-D. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
