Hi,
This is an interesting draft. I would love to see a generic
solution for network paths and receiver use cases, such as RSS.
The RFC3948 specifies one pair of UDP ports 4500-4500.
Both the IKE flow and the ESP in UDP flow should use the same UDP flow.
The draft seems to suggest new destination
On Wed, Mar 31, 2021 at 23:38:01 +, Bottorff, Paul wrote:
> Hi Antony:
>
> Below,
>
> Cheers,
>
> Paul
>
>
>
> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Antony Antony
> Sent: Wednesday, March 31, 2021 3:3
Hi,
I am happy to see this draft progressing. I am wonder
why allow changes once both sides agreed to minimal rekey?
The draft currently allow changes to cryptographic suite and TS even when
MINIMAL_REKEY_SUPPORTED is negotiated. While this is a more inclusive and
flexible approach, I feel it in
educe it
considerably.
On Wed, Nov 10, 2021 at 08:32:13AM +0100, Antony Antony wrote:
> Hi Paul,
>
> I think our draft is a better solution for the network multipath problem,
> definitely for small number of per Path SAs. Larger number of paths, say 16
> or more paths, may cau
per
> flow (not per path) which is information available to IKE. There are many
> flows for each CPU.
>
> Cheers,
>
> Paul
>
> -Original Message-
> From: Antony Antony [mailto:antony.ant...@secunet.com]
> Sent: Wednesday, November 10, 2021 12:11
Hi Paul,
This is an interesting draft. I feel there is room for this and
pwouters-ipsecme-multi-sa-performance:)
How would a receiver, a NIC in a typical X86 scenario, steer IPsec packets
to different CPUs? The document mentions the following text and I would like
to read more details.
"On r
I have read draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt.
I support adoption of the document and its publication.
-antony
On Wed, Nov 09, 2022 at 07:39:42PM +0200, Tero Kivinen wrote:
> This is two week working roup adoption call for he
> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt. If you
On Tue, Jul 25, 2023 at 07:06:47PM -0700, Lorenzo Colitti wrote:
> Dear ipsec WG,
>
> When working on a VPN implementation we found that it's very difficult to
> rely on IPv6 ESP packets because many networks drop them, so even if IKE
> negotiation succeeds, the data plane might be broken. Worse,
On Fri, Jul 28, 2023 at 01:01:39PM -0700, Lorenzo Colitti wrote:
> On Fri, Jul 28, 2023 at 11:36 AM Tero Kivinen wrote:
>
> > Sequence number is just 32-bit sequence number (always present, can
> > be used when correlating request to response).
> >
>
> Antony yesterday suggested to me that some
A Bound End-to-End Tunnel (BEET) mode for ESP
>Authors: Antony Antony
> Steffen Klassert
>Name:draft-antony-ipsecme-beet-mode-00.txt
>Pages: 21
>Dates: 2023-10-23
>
> Abstract:
>
>This document specifies a new mode for IPsec ESP, k
.
>
> Note that I am a co-author of 7402, but the Ericsson team did all the heavy
> lifting.
>
> As defined in 7402 it is used in a few products. Some implementations, I
> have been told, are in US military use.
>
> Bob
>
> On 10/27/23 06:17, Antony Antony wro
On Thu, Dec 07, 2023 at 04:43:44PM +0100, Michael Rossberg wrote:
> Hi Paul,
>
> >> 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.
> >>
On Thu, Dec 07, 2023 at 06:47:35PM -0500, Paul Wouters wrote:
> 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
ID will be updatead soon, before it
expire this month!
> Antony Antony wrote:
>
> >> If we want to implement Antony's suggestion of doing this ping on real ESP
> >> sessions as well, then that would require the ping packet to be valid ESP,
> >> i.e., pr
Hi Tero,
On Thu, Mar 14, 2024 at 19:54:56 +0200, 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?
No, I'm not aware of any related IPR.
>
> Are authors willing to be listed as authors?
Yes. I am wi
a short presentation at IPsecME session there.
regards,
-antony
On Thu, Jul 04, 2024 at 04:59:57 -0700, internet-dra...@ietf.org wrote:
> A new version of Internet-Draft draft-antony-ipsecme-encrypted-esp-ping-01.txt
> has been successfully submitted by Antony Antony and posted to the
On Thu, Jul 04, 2024 at 09:09:46AM -0400, Michael Richardson wrote:
>
> Antony Antony wrote:
> > We are proposing Encrypted ESP Ping, which will compliment/co-exist
> > with draft-colitti-ipsecme-esp-ping. We welcome feedback on this
> > proposal. Both author
sfully submitted by Antony Antony and posted to the
> IETF repository.
>
> Name: draft-antony-ipsecme-iekv2-beet-mode
> Revision: 02
> Title:IKEv2 negotiation for Bound End-to-End Tunnel (BEET) mode ESP
> Date: 2024-07-08
> Group:Individual Submission
> Pa
42
> >
> > ------
> > Type: Technical
> > Reported by: Antony Antony
> >
> > Section: 7.2
> >
> > Original Text
> > -
> > 3-255 Unassigned
> >
> > Corrected Text
> > -
Hi Michael,
On Mon, Jul 08, 2024 at 12:31:57PM -0400, Michael Richardson wrote:
>
> Antony Antony wrote:
> >> Antony Antony wrote:
> >> > We are proposing Encrypted ESP Ping, which will compliment/co-exist
> >> > with draft-colitti-ipsecm
pport.
regards,
-antony
On Tue, Jul 23, 2024 at 06:30:54PM -0400, Robert Moskowitz wrote:
> Antony and I discussed this in the hall this morning, and I will work with
> him on scoping a 7402-bis.
>
> I will have to see what xml file I can find for this
>
> Bob
>
> O
Hi Wei Pan,
On Sun, Nov 03, 2024 at 03:50:26PM +, Panwei (William) wrote:
> Hi Scott,
>
> Thank you very much for your comments.
>
> What you suggested is actually we proposed in draft v00. In our last version,
> the notification only contains the status of replay protection, and after
> b
,
-antony
On Wed, Nov 06, 2024 at 02:27:13 -0800, internet-dra...@ietf.org wrote:
> A new version of Internet-Draft draft-antony-ipsecme-iekv2-beet-mode-03.txt
> has been successfully submitted by Antony Antony and posted to the
> IETF repository.
>
> Name: draft-antony-ips
t; has been successfully submitted by Antony Antony and posted to the
> IETF repository.
>
> Name: draft-antony-ipsecme-encrypted-esp-ping
> Revision: 05
> Title:Encrypted ESP Echo Protocol
> Date: 2024-11-06
> Group:Individual Submission
> Pages:10
>
Hi Valery,
While skimming through the draft, I noticed (partial) renaming of ESN to
ARP, including the proposed IKEv2 IANA registry changes. I have a few concerns
about this.
ESN is a widely recognized term, but admittedly a confusing one, especially
since it applies to both IKEv2 negotiation an
On Thu, Nov 28, 2024 at 03:15:36PM +0300, Valery Smyslov wrote:
> Hi Antony,
>
> > Hi Valery,
> >
> > While skimming through the draft, I noticed (partial) renaming of ESN to
> > ARP,
> > including the proposed IKEv2 IANA registry changes. I have a few concerns
> > about
> > this.
> >
> > ESN
Hi,
On Thu, Nov 28, 2024 at 09:48:47AM -0500, Paul Wouters wrote:
> On Nov 28, 2024, at 07:16, Valery Smyslov wrote:
> >
> >
> > "Anti-Replay Protection (ARP)" transform type was originally named
> > "Extended Sequence Numbers (ESN)" and was referenced by that name
> > in a numb
Hi Tero,
Thank you for the revised charter proposal. It looks great.
I have a minor clarification question.
Would this cover the work proposed in draft-antony-ipsecme-ikev2-beet-mode?
I imagine it does, but I’m seeking confirmation because at the Dublin
meeting you mentioned you would need che
Hi Valery,
On Mon, Dec 02, 2024 at 06:18:35PM +0300, Valery Smyslov wrote:
> Hi Antony,
>
> > > > Number NameReference
> > > > 0 32-bit Sequential Numbers (SN) [RFC7296]
> [this ID]
> > > > 1 64-bit Sequential Numbers (ESN) [RFC7296] [this ID]
> > > >
Hi Valery,
On Mon, Dec 02, 2024 at 09:28:05AM +0300, Valery Smyslov wrote:
> Hi Tero,
>
> > Valery Smyslov writes:
> > > Hi Antony,
> > > Combining with the proposal above:
> > >
> > > Number NameReference
> > > 0 32-bit Sequential Numbers (SN) [RFC7296] [this
> > >
On Mon, Dec 02, 2024 at 05:31:00AM +0200, Tero Kivinen wrote:
> Valery Smyslov writes:
> > Hi Antony,
> > Combining with the proposal above:
> >
> > Number NameReference
> > 0 32-bit Sequential Numbers (SN) [RFC7296] [this ID]
> > 1 64-bit Sequential Numbers (ESN)
On Mon, Dec 02, 2024 at 06:54:02AM +0200, Tero Kivinen wrote:
> Antony Antony writes:
> > I have a minor clarification question.
> > Would this cover the work proposed in draft-antony-ipsecme-ikev2-beet-mode?
> >
> > I imagine it does, but I’m seeking confirm
Hi Tero,
I support advancing this document.
Valery,
I wonder Number or Numbers. May be double check?
I think following are the correct use, in singular.
"Sequence Number Properties (SNP)" instead of
"Sequence Numbers Properties (SNP)"
"Partially Transmitted 64-bit Sequential Number" instead of
"
,
-antony
On Wed, Nov 06, 2024 at 02:26:53PM +0100, Antony Antony wrote:
> Hi,
> Here is a the latest version, draft-antony-ipsecme-ikev2-beet-mode-03. This
> document is a straightforward I.D. that seeks a code point for IKEv2
> negotiation. Since IETF 120, the primary updates in this v
Hi Tero,
I support adoption of this draft.
thanks,
-antony
On Thu, Mar 13, 2025 at 10:06:20PM +0200, Tero Kivinen wrote:
> As our charter is now updated, this document is working on the
> following charter item:
>
> There is a need for tools that make it easier to debug IPsec
> conf
Hi Wei PAN,
Thanks for your support.
On Fri, Feb 28, 2025 at 10:18:13AM +, Panwei (William) wrote:
> I've read the draft and support its adoption.
>
> A few comments:
> 1. Section 1.2 should use the new boilerplate for requirements language.
> 2. In Section 2,
>If the responder declines
Hi Tero,
On Mon, Feb 17, 2025 at 04:49:15PM +0200, Tero Kivinen wrote:
> We have draft-colitti-ipsecme-esp-ping [1] and
> draft-antony-ipsecme-encrypted-esp-ping [2] both of which propose ESP
> ping, but on the different level, and each of those provide different
> level of debugging capabilities.
On Tue, Jul 08, 2025 at 11:13:33AM +0300, Valery Smyslov wrote:
> Hi Antony,
>
> > Hi Valery,
> > Thanks for your thoughts.
> >
> > I'd like to offer a different perspective—as someone who has spent a lot of
> > time debugging IKE in operational environments. In those situations, I’ve
> > often f
Hi Valery,
Thanks for your thoughts.
I'd like to offer a different perspective—as someone who has spent a lot of
time debugging IKE in operational environments. In those situations, I’ve
often found IKE error codes difficult to interpret and diagnose. This draft
aims to improve that situation f
On Mon, Jun 30, 2025 at 03:57:24PM +0300, Valery Smyslov wrote:
> Hi,
>
> I think that the problem that the draft addresses can be solved
> in more simple and elegant way. Just lift prohibition for KE transforms
> to appear in the SA payload in IKE_AUTH.
>
> Rationale. Currently all the parameter
On Tue, Jul 08, 2025 at 11:25:05AM +0300, Valery Smyslov wrote:
> Hi Antony,
>
> > > I think that the problem that the draft addresses can be solved
> > > in more simple and elegant way. Just lift prohibition for KE transforms
> > > to appear in the SA payload in IKE_AUTH.
> > >
> > > Rationale. C
On Wed, Jul 23, 2025 at 01:53:18PM +0300, Tero Kivinen wrote:
> I really need to get the slides for the IETF 123 IPsecME presentations
> as soon as possible. I will make the combined slideset today, so if
> there are no slides submitted to datatracker / to chairs before that
> we will skip that pre
42 matches
Mail list logo
