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,

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

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

[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

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   

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

e.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> > *Sub

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

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

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

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

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

[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

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

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

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

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

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

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: *

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 ___

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:

[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

[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

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

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

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

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

[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

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

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

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

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

[IPsec] IETF 116 hackathon interop testing for draft-smyslov-ipsecme-ikev2-qr-alt ?

Hi, We should have an implementation of draft-smyslov-ipsecme-ikev2-qr-alt ready for the hackathon at IETF 116. Will there be anyone to interop test with? Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] AD review of draft-ietf-ipsecme-add-ike-08

On Fri, 17 Feb 2023, Roman Danyliw wrote: ** Section 3.1 Section 3.1.5 of [I-D.ietf-add-dnr] lists a set of service parameters that are recommended to be supported by implementations. The referenced section in draft-ietf-add-dnr provides MTI and RECOMMENDED options. Are both of these

Re: [IPsec] Disabling replay protection

On Fri, 17 Feb 2023, Valery Smyslov wrote: In IPsec the replay protection is a local matter of receiver, the sender must always increment the Sequence Number as if the replay protection is always on. Right. Another approach would be to generalize the Transform Type 5 as the way to control

Re: [IPsec] Disabling replay protection

On Thu, 16 Feb 2023, Benjamin Schwartz wrote: Subject: [IPsec] Disabling replay protection 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

Re: [IPsec] Shepherd write up review for draft-ietf-ipsecme-labeled-ipsec

On Thu, 9 Feb 2023, Tero Kivinen wrote: 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. I did

Re: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-09.txt

On Mon, 6 Feb 2023, internet-dra...@ietf.org wrote: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-labeled-ipsec-09.txt A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-labeled-ipsec-09 These are the changes in response to

Re: [IPsec] [saag] IETF 114 IPsecME report

On Tue, 31 Jan 2023, Valery Smyslov wrote: The WG thought this would be a worse solution. This could be solved by adding only two new TS types TS_IPV4_ADDR_RANGE_WITH_CONSTRAINTS and TS_IPV6_ADDR_RANGE_WITH_CONSTRAINTS with a format that allows to add new constraints to the Traffic Selector.

Re: [IPsec] [saag] IETF 114 IPsecME report

On Tue, 31 Jan 2023, Valery Smyslov wrote: 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

Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

On Jan 12, 2023, at 09:06, Valery Smyslov wrote: > > Hi Paul, > >>> On Mon, 26 Dec 2022, Valery Smyslov wrote: >>> >>> Subject: Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07 >> >> I know this comment comes very late, but within the IETF we now see >> adoption happening of HPKE,

Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07

On Mon, 26 Dec 2022, Valery Smyslov wrote: Subject: Re: [IPsec] comments on draft-ietf-ipsecme-g-ikev2-07 I know this comment comes very late, but within the IETF we now see adoption happening of HPKE, Hybrid Public Key Encryption in RFC 9180. Would it make sense to redo the draft using HPKE

[IPsec] IPR disclosure for ESP SPI issue

A note on the ESP SPI overloading trick, such as used in draft-ponchon-ipsecme-anti-replay-subspaces for which SSH has IPR, they submitted an IPR statement: See https://datatracker.ietf.org/ipr/5880/ In the event that any claims of the Subject Patents are necessarily infringed

Re: [IPsec] Assessing Support for draft-smyslov-ipsecme-ikev2-qr-alt

On Mon, 19 Dec 2022, Rebecca Guthrie wrote: [speaking only as libreswan implementer] DoD has customers who are interested in incorporating a PSK into the initial IKEv2 SA. While RFC 8784 already defines a PSK mechanism, the PSK is not rolled into the encryption until creation of the first

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS)

On Thu, 15 Dec 2022, Warren Kumari wrote: Subject: Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS) Francesca / Warren: would these changes resolve your points? I kept the word deprecated as Roman pointed out that is exactly what the TLS

Re: [IPsec] Warren Kumari's Discuss on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with DISCUSS)

On Tue, 13 Dec 2022, Warren Kumari via Datatracker wrote: [speaking with author hat on] -- DISCUSS: -- Be ye not afraid -- see

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

On Wed, Dec 7, 2022 at 5:46 PM Tero Kivinen wrote: > 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

Re: [IPsec] John Scudder's No Objection on draft-ietf-ipsecme-ikev1-algo-to-historic-08: (with COMMENT)

On Wed, 7 Dec 2022, John Scudder via Datatracker wrote: -- COMMENT: -- Nits - “A few notably” should be “A few notable” - “an addition Security Context

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

Ok, all good with me. Thanks Valery! Sent using a virtual keyboard on a phone > On Nov 30, 2022, at 12:03, Valery Smyslov wrote: > > We are converging :-) > >>> I'm a bit reluctant to add all this information to the abstract. It is >>> already a bit too long >>> (since Éric and Warren

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

On Wed, 30 Nov 2022, Valery Smyslov wrote: Yes I meant the abstract :) I'm a bit reluctant to add all this information to the abstract. It is already a bit too long (since Éric and Warren suggested to augment it with the explanation text of how this design helps in situation when PQ

Re: [IPsec] Warren Kumari's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

It should really mention the new exchange it introduces in the abstract. Sent using a virtual keyboard on a phone > On Nov 30, 2022, at 03:32, Valery Smyslov wrote: > > Hi Warren, > > thank you for your comments. Please see inline. > >> -Original Message- >> From: Warren Kumari via

Re: [IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

prefer that there are not two ways to do something, as IKEv2 is already complex enough. But I guess the infrastructure needed for rekeying causes this additional method to creep in whether we want it or not. There was a request from some folks who were concerned with the possibility of DoS

[IPsec] Paul Wouters' Discuss on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with DISCUSS and COMMENT)

Paul Wouters has entered the following ballot position for draft-ietf-ipsecme-ikev2-multiple-ke-10: 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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-08.txt

On Wed, 23 Nov 2022, Tero Kivinen wrote: 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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-08.txt

On Thu, 24 Nov 2022, John Mattsson wrote: 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

Re: [IPsec] IPsecME WG Adoption call for draft-pwouters-ipsecme-multi-sa-performance

[speaking as individual] On Wed, Nov 23, 2022 at 9:32 AM Daniel Migault wrote: > I agree but in my opinion the draft has some scalability limitation and to > be useful needs to be combined with something else > That is not true. Perhaps for your use case, but not other people's use cases, such

  1   2   3   4   5   6   7   8   >