Hi Reese,
thank you for your review! Please find my comments below.
> -Original Message-
> From: Reese Enghardt via Datatracker [mailto:nore...@ietf.org]
> Sent: Tuesday, May 31, 2022 9:21 PM
> To: gen-...@ietf.org
> Cc: draft-ietf-ipsecme-rfc8229bis@ietf.org; ipsec@ietf.org;
> last-
Valery Smyslov writes:
> Thinking a bit more about the problem:
> - IPsec stream consists mostly of random data (as result of
> encryption) with uniform distribution
> - if an attacker manages to overwrite a single Length field, then
> the beginning of the next packet (including the next Length fi
Hi Tero,
> > Thinking a bit more about the problem:
> > - IPsec stream consists mostly of random data (as result of
> > encryption) with uniform distribution
> > - if an attacker manages to overwrite a single Length field, then
> > the beginning of the next packet (including the next Length field)
Hi, all,
Overall, it seems sufficient to:
- highlight how much more vulnerable this tunnel makes IPsec to DOS attacks
i.e., that single packets can cause the entire connection to need to be
reset
- indicate that there IS a way to avoid that hit by re-syncing
the sync requires a
Hi Joe,
From: secdir [mailto:secdir-boun...@ietf.org] On Behalf Of to...@strayalpha.com
Sent: Wednesday, June 01, 2022 5:43 PM
To: Valery Smyslov
Cc: draft-ietf-ipsecme-rfc8229bis@ietf.org; sec...@ietf.org;
ipsec@ietf.org; last-c...@ietf.org
Subject: Re: [secdir] [Last-Call] [IPsec] Secdir
