Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

2022-06-03 Thread Tero Kivinen
Valery Smyslov writes: > I still think that it's better to put the text about resync into the > Security considerations. I think this method is specific for Length > corruption which most probably will happen as a result of injection > attack. So, the new para in the Security considerations would

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

2022-06-01 Thread Valery Smyslov
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

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

2022-06-01 Thread Tero Kivinen
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

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

2022-05-31 Thread Valery Smyslov
Hi Tero, > Valery Smyslov writes: > > Agree, that's what is in the suggested text: > > > >o if an attacker alters the content of the Length field that > > separates packets, then the receiver will incorrectly identify the > > margins of the following packets and will drop all of

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

2022-05-31 Thread Tero Kivinen
Valery Smyslov writes: > Agree, that's what is in the suggested text: > >o if an attacker alters the content of the Length field that > separates packets, then the receiver will incorrectly identify the > margins of the following packets and will drop all of them or even >

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

2022-05-31 Thread Valery Smyslov
Hi Tero, > -Original Message- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Monday, May 30, 2022 10:26 PM > To: Valery Smyslov > Cc: 'Christian Huitema'; sec...@ietf.org; > draft-ietf-ipsecme-rfc8229bis@ietf.org; ipsec@ietf.org; last- > c...@ietf.org > Subject: RE: Secdir last

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

2022-05-30 Thread Tero Kivinen
Valery Smyslov writes: > If the TCP connection is abandoned (for any reason) and the > associated IKE SA is still up, then the IKE initiator will re-create > it. So, it is not a big deal, but definitely can influence > performance. On the other hand, an attacker who is able to alter the > packets

Re: [IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

2022-05-30 Thread Valery Smyslov
Hi Christian, thank you for your review! Please, find my comments inline. > -Original Message- > From: Christian Huitema via Datatracker [mailto:nore...@ietf.org] > Sent: Sunday, May 29, 2022 12:15 AM > To: sec...@ietf.org > Cc: draft-ietf-ipsecme-rfc8229bis@ietf.org; ipsec@ietf.org;

[IPsec] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

2022-05-28 Thread Christian Huitema via Datatracker
Reviewer: Christian Huitema Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors