On Thu, Nov 28, 2019 at 04:49:36PM +0300, Valery Smyslov wrote:
> Hi,
>
> after reading through draft-hopps-ipsecme-iptfs-01 I have some thoughts.
>
> 1. I think it's a wrong decision to support tunnel mode ESP only. IP-TFS for
> transport mode ESP
> is equally important because one of the w
Hi Valery,
On Mon, Dec 02, 2019 at 11:28:16AM +0300, Valery Smyslov wrote:
> Hi Steffen,
>
> > > It seems to me that it can be done pretty easy by linking the
> > > reassembly logic
> > > with replay protection window.
> >
> > While it looks like doing the reassembling based on ESP sequ
On Mon, Dec 02, 2019 at 06:22:26AM -0500, Christian Hopps wrote:
> > On Dec 2, 2019, at 3:01 AM, Steffen Klassert
> > wrote:
> > On Thu, Nov 28, 2019 at 04:49:36PM +0300, Valery Smyslov wrote:
> >
> >> 4. I'd like to see more text in the draft regarding
On Mon, Dec 02, 2019 at 10:57:59AM -0500, Christian Hopps wrote:
> > On Dec 2, 2019, at 9:11 AM, Steffen Klassert
> > wrote:
> > On Mon, Dec 02, 2019 at 06:22:26AM -0500, Christian Hopps wrote:
> >>> On Dec 2, 2019, at 3:01 AM, Steffen Klassert
> >>>
On Tue, Jun 02, 2020 at 11:56:48AM -0400, Christian Hopps wrote:
> > On Jun 2, 2020, at 10:21 AM, Tero Kivinen wrote:
> > Christian Hopps writes:
>
> > I would assume those questions are going to be asked from chairs or
> > area directors during the process anyways, so we need to have good
> > an
On Sun, Jun 07, 2020 at 09:43:41PM -0400, Michael Richardson wrote:
>
> Steffen Klassert wrote:
> > This alterative usecase tries to solve the 'small packet' tunneling
> > problem. Sending small packets over a tunnel usually creates quite a
> > lot
Hi Valery,
a few comments inline.
On Tue, Jul 28, 2020 at 11:13:33AM +0300, Valery Smyslov wrote:
> Hi,
>
> a few thoughts about this proposal.
>
> > * 64 bit sequence counters in each header to ease protocol handling and
> > allow for
> > replay protection in multicast groups
On Wed, Jul 29, 2020 at 04:22:15PM +0300, Tero Kivinen wrote:
> Steffen Klassert writes:
> >
> > A secret salt in the nonce would be a new requirement anyway.
> > I've checked RFC 4106 (ESP for GCM) and RFC 7634 (ESP for
> > ChaCha20-Poly1305), both don't r
On Wed, Jul 29, 2020 at 03:57:01PM +0300, Tero Kivinen wrote:
> Scott Fluhrer \(sfluhrer\) writes:
> > As for the idea of moving the integrity check value before the
> > encapsulated packet, well, that idea might help on your platform;
> > however it strikes me that the advantage would likely be fa
On Thu, Jul 30, 2020 at 10:13:57PM -0400, William Allen Simpson wrote:
> The comments thus far seem to be mixed. This is a perennial topic.
> We spent much time on it in PIPE/SIPP/IPv6.
>
> We agreed on leading for AH and trailing for ESP.
>
> When I wrote the KA9Q NOS code implementing Van Jaco
Hi,
we plan to continue our IPsec workshop series this year
after we had to stop it for two years due to COVID-19.
The workshop will take place in London, from November
3th to 4th 2022.
Some background about the event:
The IPsec workshop is organized by the 'IPsec and Network
Security Associati
Hi,
On Tue, Oct 11, 2022 at 07:14:32PM +0300, Valery Smyslov wrote:
> Hi Michael,
>
> > Valery Smyslov wrote:
> > > My main problem with the draft is the concept of "Fallback SA". This
> > SA
> > > is treated specially in the draft, which I don't think is
> > > necessary. For exampl
Hi Valery,
thanks for yor feedback! Some comments inline.
On Tue, Oct 11, 2022 at 05:37:29PM +0300, Valery Smyslov wrote:
> Hi all,
>
> as I promised at the last IETF meeting, this is my review of the
> draft-pwouters-ipsecme-multi-sa-performance draft.
> This is not a formal review of the docu
Hi Valery,
On Mon, Oct 17, 2022 at 05:10:32PM +0300, Valery Smyslov wrote:
> > >
> > > > I could guess that the fallback SA *does* require locks.
> > >
> > > It also seems to me. So I see no difference if the packet
> > > can be re-steered to a different CPU, in any case we'll have
> > > performan
Hi Valery,
On Fri, Oct 21, 2022 at 05:06:44PM +0300, Valery Smyslov wrote:
> >
> > The percpu SAs don't need locking as long as you can make sure that
> > it is never ever accessed by a remote cpu. To guarantee this, something
> > that does the 'dirt work' is needed. In our case that would be the
Hi,
over the last years, quite some work was done from different parties
to overcome some limitations of ESP to handle parallel datapaths,
QoS classes etc.
Chronologically ordered, we have:
November 2019:
https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-multiple-child-sa-00
That was re
Hi,
at the last working group meeting in London, it was quite
some interest to work on a re-design of ESP to make it fit
to the multi-cpu case, QoS classes, HW offloads etc.
We already have some proposals that try to solve related
problems in different ways:
IETF 108:
https://datatracker.ietf.o
On Tue, Nov 22, 2022 at 04:58:55PM -0500, Daniel Migault wrote:
> This draft is missing an important part which is the actual negotiation
> of the multiple SAs. A peer willing to set these multiple SAs will have to
> negotiate them anyway. Some implementations can
> handle parallel CREATE_CHILD_SA
On Tue, Nov 22, 2022 at 04:15:54PM -0500, Paul Wouters wrote:
> speaking with no hats on.
> On Mon, Nov 21, 2022 at 7:47 AM Steffen Klassert <
> steffen.klass...@secunet.com> wrote:
>
> > Is there interest in doing a virtual interim to discuss an ESP re-design?
> &
On Tue, Nov 22, 2022 at 05:16:08PM -0500, Daniel Migault wrote:
> I support Bob's suggestion.
> I also believe that multicore will be addressed by design. I do want to
> have some mechanisms like [1] to be included by design. That said, I would
> like [1] to start on ESPv3 and take the output back
On Tue, Feb 21, 2023 at 12:45:27PM -0500, Benjamin Schwartz wrote:
> On Mon, Feb 20, 2023 at 4:58 PM Michael Richardson wrote:
>
> > Tero Kivinen wrote:
> > > I mean what should other end do if the other end says he will not
> > > do anti-replay checks?
> >
> > Not send unique relay valu
:14:14 -0800
From: internet-dra...@ietf.org
To: Michael Pfeiffer , Michael Rossberg
, Steffen Klassert
Subject: New Version Notification for
draft-mrossberg-ipsecme-multiple-sequence-counters-00.txt
A new version of I-D, draft-mrossberg-ipsecme-multiple-sequence-counters-00.txt
has been
: Tue, 15 Aug 2023 03:41:29 -0700
From: internet-dra...@ietf.org
To: Michael Pfeiffer , Michael Rossberg
, Steffen Klassert
Subject: New Version Notification for
draft-mrossberg-ipsecme-multiple-sequence-counters-01.txt
A new version of I-D, draft-mrossberg-ipsecme-multiple-sequence-counters-01
On Fri, Jul 28, 2023 at 08:20:03PM +0200, Antony Antony wrote:
> 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 ev
On Wed, Jan 03, 2024 at 03:40:52PM -0500, Paul Wouters wrote:
>
>
> 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 recei
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 for
Same here,
I am not aware of any IPR and willing to be listed as author.
Steffen
On Fri, Mar 15, 2024 at 07:35:59AM +1000, Paul Wouters wrote:
> 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, Te
Hi,
thanks for your review!
On Fri, Apr 26, 2024 at 02:38:27PM -0700, Warren Kumari via Datatracker wrote:
> Warren Kumari has entered the following ballot position for
> draft-ietf-ipsecme-multi-sa-performance-06: Discuss
>
> When responding, please keep the subject line intact and reply to all
Hi,
On Wed, Apr 17, 2024 at 12:13:19PM +, Marcus Ihlar wrote:
> I think it would be sufficient to include a paragraph that mentions that this
> solution can introduce packet reordering and variable delays and that packet
> scheduling/load-balancing implementations should take this into
> co
optional padding to align the cipertext to the need
of the peers.
Steffen
- Forwarded message from internet-dra...@ietf.org -
Date: Tue, 28 May 2024 01:55:54 -0700
From: internet-dra...@ietf.org
To: Antony Antony , Steffen Klassert
Subject: New Version Notification for draft-klassert-i
On Thu, Jun 06, 2024 at 01:54:30PM +, Doyle, Stephen wrote:
> > (3) Fields that should be match-able by hardware should appear at the
> > beginning. The FID, for example, seems like a field that should go to the
> > beginning.
>
> +1 for this.
>
> With the current WESPv2 header format, an
On Wed, Jun 05, 2024 at 04:44:25PM +0200, Boris Pismenny wrote:
> Hi,
>
> I have a few questions and a few comments on how
> to make this more hardware friendly, like PSP.
> Note that making it hardware friendly will likely
> improve highly tuned software performance too.
>
> **Questions**:
> (1)
On Wed, Jun 19, 2024 at 12:01:32PM +0200, Boris Pismenny wrote:
> On 07.06.2024 10:13, Steffen Klassert wrote:
> > On Wed, Jun 05, 2024 at 04:44:25PM +0200, Boris Pismenny wrote:
>
> I think that negotiation is very desirable given that it
> is constant because it will allow
rg
To: Antony Antony , Steffen Klassert
Subject: New Version Notification for draft-klassert-ipsecme-wespv2-01.txt
A new version of Internet-Draft draft-klassert-ipsecme-wespv2-01.txt has been
successfully submitted by Steffen Klassert and posted to the
IETF repository.
Name: draft-kla
On Fri, Aug 16, 2024 at 08:09:31AM +, Panwei (William) wrote:
> Tero Kivinen writes:
> > I would like to add one more there, i.e., ESN sent as 64-bit sequence
> > number (i.e. transmitting full ESN value in packet) in such way that you
> > send lower 32-bits first, and then you add
On Fri, Aug 16, 2024 at 07:32:06PM +0300, Tero Kivinen wrote:
> Paul Wouters writes:
> > 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
> >
Hi,
I have some comments on draft-ietf-ipsecme-diet-esp-02.txt.
Section 2:
Old:
An ESP packet is composed of an ESP Header, an ESP Payload and an
Integrity Check Value (ICV). and ESP Trailer.
Maybe better:
An ESP packet is composed of an ESP Header, an ESP Payload, an
ESP Trailer
Hi Tero,
the new charter text covers all our work, so looks good!
On Sat, Nov 16, 2024 at 02:52:13PM +0200, Tero Kivinen wrote:
>
> The ESPv3 protocol was defined in 2005 and there has been seen that
> there might be some need to make enhancements to it. The working group
> will analyze the poss
On Thu, Dec 05, 2024 at 12:38:56AM +0200, Tero Kivinen wrote:
> Michael Richardson writes:
> >
> > Tero Kivinen wrote:
> > > Postquantum Cryptography brings new authentication methods. The
> >
> > (rant about "quantum-safe" term omitted)
> >
> > ...
> >
> > > The ESPv3 protocol was defined
Hi,
thanks for the feedback! Please find our comments inline.
On Fri, Jan 03, 2025 at 09:26:29AM +, Panwei (William) wrote:
> Hi,
>
> I’ve read the current v01. I know this is still in the early version, and I’m
> happy to see it evolving and contribute to it. Here below are my initial
> c
On Fri, Dec 13, 2024 at 11:22:00AM +0300, Valery Smyslov wrote:
> Hi Steffen,
>
> > Hi,
> >
> > I've read the document and I support it.
> >
> > One nit:
> >
> > The document talkes about 'anti-replay protection' which sounds a bit odd.
> > We
> > protect against replay, not anti-replay.
> >
Hi,
I've read the document and I support it.
One nit:
The document talkes about 'anti-replay protection' which sounds
a bit odd. We protect against replay, not anti-replay.
ESP RFC 4303 talkes about 'anti-replay service' or just 'anti-replay'.
Maybe the document can be aligned with terms used i
On Thu, Jan 09, 2025 at 10:23:48PM -0500, Michael Richardson wrote:
>
> Hi, with some help from Carsten and his uplift tools, I have converted
> RFC4301 and RFC4303 to markdown. They are at:
>https://github.com/mcr/rfc4301bis
>
> I recognize that we aren't going with Internet Standard work a
I read the draft and support adoption.
Steffen
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
> configurations. T
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.
I have r
We published a new version of draft-klassert-ipsecme-eesp.
Comments welcome!
Steffen
- Forwarded message from internet-dra...@ietf.org -
Date: Wed, 26 Feb 2025 02:35:27 -0800
From: internet-dra...@ietf.org
To: Antony Antony , Christian Hopps
, Steffen Klassert
Subject: New
From: internet-dra...@ietf.org
To: Antony Antony , Steffen Klassert
, Tobias Brunner
, Valery Smyslov
Subject: New Version Notification for draft-klassert-ipsecme-eesp-ikev2-00.txt
A new version of Internet-Draft draft-klassert-ipsecme-eesp-ikev2-00.txt has
been successfully submitted by
Hi,
we plan to continue our IPsec workshop series this year
right before IETF 123.
The workshop will take place in Madrid, from July
17th to 18th 2025.
Some background to the event:
The IPsec workshop is organized by the 'IPsec and Network
Security Association' and was held first time in 2018.
Hi Yoav,
I'd like to request a 15 minutes slot to discuss
draft-ietf-ipsecme-eesp.
Thanks,
Steffen
On Tue, Jul 01, 2025 at 07:15:54PM +0300, Yoav Nir wrote:
> Hi, all
>
> In case you missed it, we have the following 2-hour slot for IETF 123:
>
>ipsecme Session 1 (2:00 requested)
>Thur
49 matches
Mail list logo
