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
> >
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
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 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
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 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
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
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
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
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
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
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 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
: 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
: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
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
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, 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 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
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
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 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 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,
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,
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,
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
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
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 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
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 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
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 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 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
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 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
36 matches
Mail list logo
