[IPsec] Re: New Version Notification for draft-antony-ipsecme-iekv2-beet-mode-03.txt

On Nov 6, 2024, at 13:27, Antony Antony wrote: > > As such, this document can progress independently. > > I would like to request the working group’s adoption of > draft-antony-ipsecme-ikev2-beet-mode-03. It is ready. I am supportive of this work continuing here. Paul

[IPsec] Re: draft-kampanakis-ml-kem-ikev2

On Tue, Aug 27, 2024 at 11:51 AM Kampanakis, Panos wrote: > CFRG had https://datatracker.ietf.org/doc/draft-cfrg-schwabe-kyber/ , > https://bwesterb.github.io/draft-schwabe-cfrg-kyber/draft-cfrg-schwabe-kyber.html > for Kyber, but that was for the draft00 versions of Kyber deployed in early > TLS

[IPsec] Re: draft-kampanakis-ml-kem-ikev2

On Mon, Aug 26, 2024 at 1:51 PM Scott Fluhrer (sfluhrer) wrote: > I (and I don’t believe I am alone in this) would like to see an ML-KEM RFC > for IKE; how can we make it happen? > > > > From what I see, the next step (now that the authors have updated it to > specify the final version of ML-KEM)

[IPsec] Re: Comments on draft-pan-ipsecme-anti-replay-notification

On Fri, Aug 16, 2024 at 10:09 AM Tero Kivinen wrote: > > The difference in implementations is minimal, but sending lower > 32-bits first keeps the ESP backward compatible with different > firewall, deep packet inspection etc middleboxes, which might check > sequence number and filter stuff if it

[IPsec] Re: Algorithm Implementation Requirements update

On Fri, Aug 16, 2024 at 10:28 AM Tero Kivinen wrote: > Paul Wouters writes: > > > On the other hand I do think Group 14 is something that most likely > > > needs to be updated... > > > > Yes, some standards like PCI are sun setting finite field DH. The > >

[IPsec] Re: AUTH_HMAC_SHA1_96 not formally deprecated

On Mon, 12 Aug 2024, Tero Kivinen wrote: Because AUTH_HMAC_SHA1_96 used to be mandatory it was moved t MUST-, not to SHOULD NOT or MUST NOT while AUTH_HMAC_SHA2_256_128 was made MUST. In the next update of the Algorithm Implementation Requirements and Usage Guidance for IKEv2 (RFC8247) and E

[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

> On Aug 10, 2024, at 20:35, Tero Kivinen wrote: > >  > Perhaps instead of reason text we have generic enumeration of close > reasons like we have now, but in addition to that we have 32-bit > vendor specific reason code. The vendors could then use that vendor > specific code field to put in so

[IPsec] Re: Comments on draft-pwouters-ipsecme-child-pfs-info

On Thu, Aug 1, 2024 at 10:04 AM Valery Smyslov wrote: > Hi Paul, > > > > That assumes that you allow a different KE from the IKE KE for the child? > That is > > questionable at best to begin with. > > > > I meant that the policy may be: > > > > - use AES-GCM with P256 > >

[IPsec] Re: Comments on draft-pwouters-ipsecme-child-pfs-info

On Thu, Aug 1, 2024 at 4:21 AM Valery Smyslov wrote: > Hi, > > I also have some comments on draft-pwouters-ipsecme-child-pfs-info. > > >From the Introduction I learned that the problem this draft is trying to > address is the > lack of knowledge at the time the initial Child SA is being created i

[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

On Wed, Jul 31, 2024 at 3:32 AM Valery Smyslov wrote: > Hi Paul, > > > > (I think gmail is reaching its limits on careful quoting context, hope I > get it all right) > > > > I will mark my replies with this color. > Thanks, that was very helpful! > > Will it help your debuggi

[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

(I think gmail is reaching its limits on careful quoting context, hope I get it all right) On Tue, Jul 30, 2024 at 10:49 AM Valery Smyslov wrote: > Hi Paul, > > > > On Mon, Jul 29, 2024 at 6:18 AM Valery Smyslov > wrote: > > Hi, > > I have some comments on draft-pwouters-ipsecme-delete-info th

[IPsec] Re: Comments on draft-pan-ipsecme-anti-replay-notification

On Tue, Jul 30, 2024 at 11:16 AM Valery Smyslov wrote: > Hi Paul, > > > > I think that the following assertion in the draft is wrong: > >Although >ESN is good to avoid the sequence number running out in a short >period, there is a prerequisite for using ESN - RFC 4302 and RFC 4303 >

[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

On Mon, Jul 29, 2024 at 6:18 AM Valery Smyslov wrote: > Hi, > > I have some comments on draft-pwouters-ipsecme-delete-info that I tried to > express at IETF120, > but due to lack of time they were not responded to. > > 1. I'm very much concerned with the "Delete Reason Text" field. My primary > q

[IPsec] Re: Comments on draft-pan-ipsecme-anti-replay-notification

On Mon, Jul 29, 2024 at 6:37 AM Valery Smyslov wrote: > > I think that the following assertion in the draft is wrong: > >Although >ESN is good to avoid the sequence number running out in a short >period, there is a prerequisite for using ESN - RFC 4302 and RFC 4303 >both require E

[IPsec] draft-smyslov-ipsecme-ikev2-qr-alt update

Hi, Valery and Vukasin worked on interop testing a few weeks ago of draft-smyslov-ipsecme-ikev2-qr-alt-09 and after some code fixes on both implementations we got successful interop on the success and failure paths. We believe this document is ready for WGLC Paul _

[IPsec] Re: [Technical Errata Reported] RFC9347 (8042)

On Mon, 22 Jul 2024, Alice Russo wrote: Paul, FYI, the "Original text" in this report has been updated to match the actual RFC (https://www.rfc-editor.org/rfc/rfc9347.html#section-7.2). As discussed, this line contains 2 errors (the range and 'Reserved' where it should have been 'Unassigned'

[IPsec] Re: [Technical Errata Reported] RFC9347 (8042)

On Mon, 22 Jul 2024, RFC Errata System wrote: Subject: [IPsec] [Technical Errata Reported] RFC9347 (8042) The following errata report has been submitted for RFC9347, "Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS)".

[IPsec] Re: Are there any issues of reusing IPsec key for generating Authentication Code?

On Tue, 9 Jul 2024, Linda Dunbar wrote: 1. The IPsec tunnel itself provides a secure channel for transmitting the authentication keys. This ensures that the keys are protected from eavesdropping or tampering during distribution. 2. Reuse the existing IPsec keys as input to a key derivatio

Re: [IPsec] Murray Kucherawy's No Objection on draft-ietf-ipsecme-multi-sa-performance-08: (with COMMENT)

On Thu, May 2, 2024 at 2:28 AM Murray Kucherawy via Datatracker < nore...@ietf.org> wrote: > > I realize there's terminology imported from elsewhere, but it would be > helpful > (and cheap) to expand things like "SA" on first use anyway. > Done > In Section 6, "it is there for" should be "it is

Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-multi-sa-performance-08: (with COMMENT)

On Thu, May 2, 2024 at 7:29 AM Éric Vyncke via Datatracker wrote: > > # COMMENTS (non-blocking) > > ## Unbalanced ? > > It has been a long time since I worked with IPsec, but I have a small > concern > about this proposal: one peer will use its own selector/SADB to select a > child > SA and the a

Re: [IPsec] Gunter Van de Velde's No Objection on draft-ietf-ipsecme-multi-sa-performance-06: (with COMMENT)

On Mon, Apr 22, 2024 at 9:23 AM Gunter Van de Velde via Datatracker < nore...@ietf.org> wrote: > > ###COMMENTS: > ##generic comments: > The abstract implies the possibility of utilizing various resources to > enhance > performance for the same traffic selector, yet the document consistently > ment

Re: [IPsec] John Scudder's No Objection on draft-ietf-ipsecme-multi-sa-performance-08: (with COMMENT)

On Wed, 1 May 2024, John Scudder via Datatracker wrote: Thanks for the document. Just one note: ### Section 1 I don't understand this sentence: When an IKEv2 peer is receiving additional Child SA's for a single set of Traffic Selectors than it is willing to create, it can return an erro

Re: [IPsec] Mahesh Jethanandani's No Objection on draft-ietf-ipsecme-multi-sa-performance-08: (with COMMENT)

On Mon, 29 Apr 2024, Mahesh Jethanandani via Datatracker wrote: From an operational perspective, the shepherd write-up brought up the question of how this draft would be operationalized. In other words, is there an augment of the existing YANG model planned that would update the model to add the

Re: [IPsec] Murray Kucherawy's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

On Thu, 18 Apr 2024, Valery Smyslov wrote: -- COMMENT: -- The shepherd writeup says there are implementers, but no implementations. Is that right? Yes, that

Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

On Thu, 18 Apr 2024, Valery Smyslov wrote: OK, then how about (Section 3): CURRENT: The receiving party may take this information into consideration when selecting an algorithm for its authentication if several alternatives are available. NEW: The receiving party may take this inform

Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

> On Apr 18, 2024, at 04:09, Valery Smyslov wrote: > >  >> >> Note that the IANA registry involved here was renamed since the latest draft >> was written :) >> >> Notify Message Type -> Notify Message Status Type >> >> "IKEv2 Notify Message Types - Status Types" -> IKEv2 Notify Message Stat

[IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

Paul Wouters has entered the following ballot position for draft-ietf-ipsecme-ikev2-auth-announce-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [IPsec] [Last-Call] Tsvart last call review of draft-ietf-ipsecme-multi-sa-performance-06

On Wed, 10 Apr 2024, Marcus Ihlar via Datatracker wrote: Thanks for your review. Load balancing algorithms and policies are likely best left as implementation details but I do think a paragraph in the operational considerations section could be warranted. We had some Linux details in there be

Re: [IPsec] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

I can live with that.PaulSent using a virtual keyboard on a phoneOn Apr 2, 2024, at 03:10, Valery Smyslov wrote:Hi Paul, On Mon, Apr 1, 2024 at 9:08 AM Valery Smyslov wrote: I've added the following sentence to the Introduction:   Since IKEv2 doesn't allow to use multiple   authen

Re: [IPsec] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

On Mon, Apr 1, 2024 at 9:08 AM Valery Smyslov wrote: I've added the following sentence to the Introduction: > >Since IKEv2 doesn't allow to use multiple >authentication methods and doesn't provide means for peers to >indicate to the other side which authentication methods they support

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

On Wed, 27 Mar 2024, Panwei (William) wrote: Thanks for your clarification. I'm much clearer about the problems now. > > When you find out that the IKEv2 negotiation succeeds but ESP > > traffic can't get through, what more information will you get > > from sending the ESPping and not

Re: [IPsec] Artart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

> On Mar 23, 2024, at 13:00, Marc Blanchet via Datatracker > wrote: > > Comment 1) > The draft does not specify any fallback procedure or how to handle the > situation when no proper authentication method can be chosen by one of the > peers. Maybe it is specified elsewhere? Or maybe it is so o

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 i

Re: [IPsec] AD Review of draft-ietf-ipsecme-multi-sa-performance-05

ssion 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: [IP

Re: [IPsec] AD Review of draft-ietf-ipsecme-multi-sa-performance-05

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: ** Abstract. Editorial. s/crypto/cryptography/ Fixed. ** Section 1. Most IPsec implementations are currently limited to using one

Re: [IPsec] I-D Action: draft-ietf-ipsecme-multi-sa-performance-04.txt

On Mon, 18 Mar 2024, Tero Kivinen wrote: Internet-Draft draft-ietf-ipsecme-multi-sa-performance-04.txt is now 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? that was an operator error on my

Re: [IPsec] IPR confirmations for draft-ietf-ipsecme-multi-sa-performance

I am not aware of any IPR, willing to be listed as author. Paul Sent using a virtual keyboard on a phone > On Mar 15, 2024, at 03:55, Tero Kivinen wrote: > > Are any authors of the draft-ietf-ipsecme-multi-sa-performance (or > anybody else) aware of any IPRs related to this draft? > > Are au

Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt

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

Re: [IPsec] New Version Notification for draft-guo-ipsecme-ikev2-using-shangmi-00.txt

On Mon, 29 Jan 2024, Xialiang(Frank, IP Security Standard) wrote: We have submitted this new draft “Using ShangMi in the Internet Key Exchange Protocol Version 2 (IKEv2)”, which defines a set of cryptographic transforms for using in the IKEv2 based on Chinese cryptographic standard algorithms

Re: [IPsec] I-D Action: draft-he-ipsecme-vpn-shared-ipsecsa-00.txt

Initial thought while having morning coffee. I can see how you want an extra SPD selector for the VPN ID - but maybe call it Namespace ID or something else as VPN ID is confusing. Your gateway that needs to support say 256 VPN IDs could split up its SPI range so it can detect which VPN to send

[IPsec] DELETE_REASON notify (draft-pwouters-ipsecme-delete-info)

At IETF-118 I presented the issue on reason of deletion. From the Introduction: The IKEv2 [RFC7296] protocol supports sending a Delete Notify message, but this message cannot convey the reason why a particular Child SA or IKE SA is being deleted. It can be useful

[IPsec] draft-pwouters-ipsecme-child-pfs-info

I agreed to write up a draft to discuss the issue regarding rekeying the initial Child SA and KE/PFS settings. Previous discussion/presentation at IETF118: https://datatracker.ietf.org/meeting/118/materials/slides-118-ipsecme-ikev2-dhke-interop-issues-00 Initial proposed draft: https://data

Re: [IPsec] What's the most reasonable way for the responder to handle the request containing unknown Key Exchange methods

On Mon, 5 Feb 2024, Panwei (William) wrote: Regarding how the responder handles the request containing the new Key Exchange methods (old name was DH Group) that it doesn’t understand, I’ve had a discussion with someone, but we failed to agree with each other due to different interpretations of

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt

On Tue, 30 Jan 2024, Lorenzo Colitti wrote: Not necessarily. A VPN client might know for sure that the server it wants to talk to supports ESP ping. Before the IKE handshake, it could send the ping, and if no response came back, it simply wouldn't bother with negotiating ESP or IPv6 at all and

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt

On Jan 29, 2024, at 13:51, Jen Linkova wrote: > >  > It looks like the ESP ping capability needs to be negotiated. It doesn’t need to be negotiated, just announced. > The question is: shall it be another IKEv2 Configuration attribute or smth > else? Use a plain Notify payload. Of course, it

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt

On Fri, 12 Jan 2024, Antony Antony wrote: For a basic use case, any response would suffice. The essential requirement is the ability to send a request and receive a response from the IPsec peer, which is why I proposed the minimal solution to begin with. I disagree. VPN protocols are actively

[IPsec] RFC 4303 ESN and replay protection entanglement

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

Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension

On Dec 11, 2023, at 12:03, Hannes Tschofenig wrote:I have, however, heard about uses of WireGuard on Linux-based IoT devices (these are non-constrained devices, obviously) with the argument that it is simple to use and efficient.It’s actually far less efficient because it only supports

Re: [IPsec] WG Adoption calls for draft-mglt-ipsecme-diet-esp and draft-mglt-ipsecme-ikev2-diet-esp-extension

> > On Dec 11, 2023, at 08:53, Daniel Migault wrote: > >  > What is not completely clear to me now is how we will be able to have/make > public implementations for linux implementation and potentially *Swan > projects. It is a bit too early for now, but I am hoping to have a path in > the n

Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed.

On Thu, 7 Dec 2023, Michael Rossberg wrote: I would actually like to refrain from writing 2 * 1.024 keys from the control plane to the data plane, just because a single IKE SA rekeyed... If you rekey the IKE SA, there is no change to the Child SA's. The new IKE SA inherits the existing Child S

Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed.

On Thu, 7 Dec 2023, Michael Rossberg wrote: I would actually like to refrain from writing 2 * 1.024 keys from the control plane to the data plane, just because a single IKE SA rekeyed... If you rekey the IKE SA, there is no change to the Child SA's. The new IKE SA inherits the existing Child S

Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed.

On Thu, 7 Dec 2023, Pierre Pfister (ppfister) wrote: My understanding is that when PFS is enabled, the first CHILD_SA leverages the IKE SA key, but any further CREATE_CHILD_SA (which is the case when setting up more “sub-SAs”) would use separate keys. >From RFC5996:   Although ESP and AH do

Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed.

On Mon, 4 Dec 2023, Pierre Pfister (ppfister) wrote: We have received pushbacks from Tero. But I am curious to know if other people share the same opinion, or not. I think I do. At least, I see a use case for this, but I don't see it based on your current explanations. To bootstrap the conv

Re: [IPsec] Why ipsecme-anti-replay-subspaces is needed.

On Mon, 4 Dec 2023, Ben Schwartz wrote: As I've mentioned previously, I think this draft is valuable for "network-to-network" tunneling, where the sender and receiver are both represented by a large (and evolving) collection of gateways (perhaps sharing IPs via anycast). I don't understand w

Re: [IPsec] WG Adoption call for draft-smyslov-ipsecme-ikev2-qr-alt

On Mon, 27 Nov 2023, Tero Kivinen wrote: 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

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance passed

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

Re: [IPsec] Interesting attacks on PKCS#v1.5 in IKE

On Thu, 16 Nov 2023, Valery Smyslov wrote: I still think that PAKE is different in its use cases, than PSK. PAKE is good when the secret is not stored on the host at all, only user knows it (so, if your notebook is stolen, the theft gets nothing). PSK assumes that they are stored somewhere, so t

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

On Tue, 14 Nov 2023, Valery Smyslov wrote: I support publication of this draft. I'm glad authors took my points into consideration while preparing the latest version. I do have some comments though. 1. Section 1 IKEv2 [RFC7296] already allows installing multiple Child SAs with identical T

Re: [IPsec] Interesting attacks on PKCS#v1.5 in IKE

On Wed, 15 Nov 2023, Valery Smyslov wrote: - Maybe look at a new EAP method to prevent AUTH payload from the server to be send before client is authenticated. If EAP is employed the server sends AUTH twice - first time before any EAP method starts and second time - at the end of EAP protoco

[IPsec] Interesting attacks on PKCS#v1.5 in IKE

-- Forwarded message -- Date: Wed, 15 Nov 2023 09:12:17 From: Paul Wouters via Devel Cc: de...@linux-ipsec.org To: Andrew Cagney Subject: Re: [devel-ipsec] Fwd: Strange IPSEC traffic On Tue, 14 Nov 2023, Andrew Cagney via Devel wrote: Subject: Re: [devel-ipsec] Fwd

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

On Wed, 15 Nov 2023, Yoav Nir wrote: Do you think it be better for each end to announce a maximum ahead of time? (At negotiation of the first child SA) I think so, but not completely sure. Suppose one peer is willing to go to 32 parallel SAs, while the other is going to stop at 8, because on

Re: [IPsec] AD Review of draft-ietf-ipsecme-ikev2-auth-announce-04

On Oct 26, 2023, at 18:26, Tero Kivinen wrote: > >  > 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 :-) The only winning move is not to play.___ IPsec mailing

Re: [IPsec] AD Review of draft-ietf-ipsecme-ikev2-auth-announce-04

On Thu, 26 Oct 2023, Valery Smyslov wrote: I also have off-the-list conversation with Daniel Van Geest, who made some good proposals, which I would also like to include in the draft if the WG agrees. 1. Specify that auth announcements are included into the SUPPORTED_AUTH_METHODS notification

Re: [IPsec] New Version Notification for draft-pwouters-ipsecme-delete-info-00.txt

wrote: > A new version of Internet-Draft draft-pwouters-ipsecme-delete-info-00.txt > has > been successfully submitted by Paul Wouters and posted to the > IETF repository. > > Name: draft-pwouters-ipsecme-delete-info > Revision: 00 > Title:IKEv2 support for specifyin

Re: [IPsec] I-D Action: draft-ietf-ipsecme-multi-sa-performance-02.txt

Name:draft-ietf-ipsecme-multi-sa-performance-02.txt A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-multi-sa-performance-02 This draft versions simplifies the negotiation and no longer tries to negotiate a number of Child

Re: [IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 for your review)

d...@orange.com > *Sent:* Thursday, October 5, 2023 2:46 AM > *To:* Tommy Pauly ; Paul Wouters > *Cc:* ipsec@ietf.org ; Valery Smyslov ; > ipsecme-...@ietf.org ; ipsecme-cha...@ietf.org < > ipsecme-cha...@ietf.org>; Dan Wing ; Tirumaleswar Reddy < > kond...@gmail.com>

Re: [IPsec] SvcParams encoding (was RE: AUTH48: RFC-to-be 9464 for your review)

As I said over the other side, I prefer presentation format. Here that is even more true than over at the dhcp server because ike daemons (server AND client) tend to not implement dns wire format. Presentation format would be to reject this change. But whichever is picked, if I am in the rough,

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt

On Wed, 6 Sep 2023, Valery Smyslov wrote: I would change this to: "After completing an IKE negotiation, an IPsec peer wishing to verify the viability of the current network path for ESP packets MAY initiate an ESP Echo Request" As in, you can do it immediately after the IKE SA is established,

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-00.txt

On Wed, 6 Sep 2023, Antony Antony wrote: Here is a proposed text for the I-D. "Upon completing an IKE negotiation, an IPsec peer wishing to ascertain the viability of the path for ESP packets MAY initiate an ESP Echo Request I would change this to: "After completing an IKE negotiation, an IP

Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-qr-alt-07.txt

On Fri, Aug 25, 2023 at 7:12 AM Vukašin Karadžić wrote: > Hi, > > I agree with Rebecca's suggestion. Especially the first one, regarding > introducing the USE_EARLY_PPK notify, since it seems the introduction would > also make the implementation of the draft (combined with RFC 8784) > 'cleaner'/e

Re: [IPsec] wrong and missing IANA ikev2/esp reference ?

On Wed, Aug 16, 2023 at 5:17 AM Tero Kivinen wrote: > 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. Th

Re: [IPsec] wrong and missing IANA ikev2/esp reference ?

On Mon, Aug 14, 2023 at 12:00 PM Paul Wouters wrote: > > 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_C

Re: [IPsec] Questions for draft-ponchon-ipsecme-anti-replay-subspaces

On Mon, 14 Aug 2023, Aseem Choudhary wrote: 1. Yes, you're correct there is still reordering potentially happening between the endpoints of the tunnel. However, the intention behind using the subspace is to limit the potential reordering of packets at the tunnel endpoints. By assigning packets

[IPsec] wrong and missing IANA ikev2/esp reference ?

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. If some

Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification

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...

Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification

On Wed, Aug 2, 2023 at 9:17 PM Michael Richardson wrote: > > Paul Wouters wrote: > >> Christian Hopps wrote: >> The ingress node > >> encrypts this packet and adds the IPsec >> encapsulation, and this > >> IPsec-processed pa

Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification

On Tue, 1 Aug 2023, Daniel Migault wrote: [The quoting got mangled in Daniel's message] If an incoming Encrypted packet is larger than the Link MTU How can than be? You mean you received an ESP or ESPinUDP that after decrypting was too large for the link you need to send the decrypted packe

Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification

On Wed, 2 Aug 2023, Michael Richardson wrote: Christian Hopps wrote: >> The ingress node encrypts this packet and adds the IPsec >> encapsulation, and this IPsec-processed packet is also larger than the >> Link MTU. The ingress node fragments this IPsec-processed packet and >> sends

Re: [IPsec] -ikev2-mtu-dect: IKEv2 PTB Notification

On Aug 1, 2023, at 12:56, Daniel Migault wrote: > >  > Hi Ben, > Just trying to position our understanding of the position between the ICMP > PTB and the IKE PTB. > If an incoming Encrypted packet is larger than the Link MTU How can than be? You mean you received an ESP or ESPinUDP that aft

Re: [IPsec] IPsecME errata items

Thanks everyone for the feedback on these erratas. I've processed them accordingly. Thanks! Paul On Fri, Jul 28, 2023 at 1:48 AM Tobias Brunner wrote: > Hi Tero, > > > https://www.rfc-editor.org/errata/eid6339 > > > > This complains that "Curve25519 and Curve448 for IKEv2" RFC > >

Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update

On Jul 25, 2023, at 00:19, Tobias Brunner wrote: > > > > That's exactly what I'm proposing. Make it *mandatory* that the first > rekeying of the Child SA that's created with IKE_AUTH is a regular one. > Because if that's not the case, it might be impossible for a responder > to deduce what the

Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update

On Fri, 21 Jul 2023, Tobias Brunner wrote: I tried to formulate and solve the issues discussed at the previous meeting. There was no clear outcome (based on rereading the minutes) so please check the changes and let the authors know if you disagree. Thanks for the updates. Some notes: * mayb

Re: [IPsec] IPsecME WG Agenda for IETF 117

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 😜 Paul ___ IP

Re: [IPsec] IETF 117 agenda items

On Tue, Jul 11, 2023 at 4:52 PM Rebecca Guthrie wrote: > Greetings, > > Will there be an adoption call for draft-smslov-ipsecme-ikev2-qr-alt-08? I > support adoption, but if the group thinks it needs more discussion first, > I'd like to request that it be added to the agenda. We haven't really

[IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update

Hi, I tried to formulate and solve the issues discussed at the previous meeting. There was no clear outcome (based on rereading the minutes) so please check the changes and let the authors know if you disagree. Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-sa-ts-pay

[IPsec] IKEv2: how to respond to REKEY_SA with bad protoid?

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 i

[IPsec] Paul Wouters' No Objection on draft-ietf-ipsecme-add-ike-13: (with COMMENT)

Paul Wouters has entered the following ballot position for draft-ietf-ipsecme-add-ike-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-add-ike-11: (with DISCUSS and COMMENT)

On Wed, 10 May 2023, Valery Smyslov wrote: I do think that is very confusing. I would prefer to see the field described once to make it more clear there is only one format. Do you think the figure above should be added to the document with fields description? No, I thought using just one fig

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-add-ike-11: (with DISCUSS and COMMENT)

On Wed, 10 May 2023, mohamed.boucad...@orange.com wrote: Thanks for the changes to address my concerns. The idea here is that the other "1" should also be described here. [Med] That other "1" is about the address count. This is why we are referring to an "address" not "addresses". Made this

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-add-ike-11: (with DISCUSS and COMMENT)

On Tue, 25 Apr 2023, Valery Smyslov wrote: Actually, the format is the same for both request and response, but depending on Num Hash Algs and AND Length and also on Length, some fields may be omitted. The most generic format is: 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

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-add-ike-11: (with DISCUSS and COMMENT)

On Tue, 25 Apr 2023, mohamed.boucad...@orange.com wrote: #2 Updates RFC 8598 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 This clearly u

Re: [IPsec] Robert Wilton's Discuss on draft-ietf-ipsecme-add-ike-11: (with DISCUSS and COMMENT)

> On Apr 27, 2023, at 05:48, mohamed.boucad...@orange.com wrote: > > [Med] Do53 is widely used but without a reference. I prefer to maintain in > this section. Thanks. It’s only in use for the few encrypted DNS related drafts. I wouldn’t say “wide use”. I also think using “unencrypted DNS”

[IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-add-ike-11: (with DISCUSS and COMMENT)

Paul Wouters has entered the following ballot position for draft-ietf-ipsecme-add-ike-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to

Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-auth-announce-02

On Fri, Apr 14, 2023 at 10:00 AM Valery Smyslov wrote: > > OK, I see your point. We use similar approach, but payload processing > is also dependent on the exchange it is encountered (in addition to its > type), > so there is no problem to have same payloads in different exchanges for > our imple

Re: [IPsec] [Last-Call] Genart last call review of draft-ietf-ipsecme-labeled-ipsec-10

On Mon, 10 Apr 2023, Ines Robles via Datatracker wrote: The document is well written and easy to read. Thanks :) Nits/editorial comments: Section 3.2: "198.51.0/24" --> "198.51.100.0/24" ? Fixed in -11. Question: Section 2.1, the Security Label should be at least of one octet. Is there

Re: [IPsec] AD Review of draft-ietf-ipsecme-labeled-ipsec-09

On Sat, 18 Mar 2023, Roman Danyliw wrote: Hi Roman, Thanks for the AD review. I conducted an AD review of draft-ietf-ipsecme-labeled-ipsec-09. Thanks for the work on this document. I have a few editorial recommendations that can be handled concurrently to IETF Last Call. ** Section 2.2.

Re: [IPsec] [secdir] Secdir last call review of draft-ietf-ipsecme-labeled-ipsec-09

On Tue, 4 Apr 2023, Stephen Farrell via Datatracker wrote: Hi Stephen, Thanks for the secdir review! This is basically fine, but I think there's one issue that isn't quite a nit: 1.3: "Typically, the other TS_TYPE would be of type TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE." That seems a bi

Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-auth-announce-02

On Wed, 29 Mar 2023, Valery Smyslov wrote: Actually, there is no ambiguity here. The first appearance of SUPPORTED_AUTH_METHODS anywhere means that this extension is supported by the party sent it. The content provides supported methods and if the content in responder's message is empty, then

[IPsec] Review of draft-ietf-ipsecme-ikev2-auth-announce-02

Sorry for the (very) late review. I support the document but have a few comments and questions. The SUPPORTED_AUTH_METHODS NOTIFY is used for multiple purposes. One of these methods (with no payload data) is used for two different things. Would it be better to split this in two? eg SUPPORTED_AU

Re: [IPsec] RISAV proposal at SECDISPATCH

On Tue, 14 Mar 2023, Michael Richardson wrote: [speaking as individual] AH has essentially no deployment at this point, and so this is rather a good plan. We have been trying to kill it in favour of ESP-NULL, so I'm not sure I would want to encourage new deployment of it at this point. I thi

  1   2   3   4   5   6   7   8   9   >