[IPsec] Re: Need 10 minutes slot at the IPsecme session

Hi, Linda, Notes below. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Nov 4, 2024, at 2:06 AM, Linda Dunbar wrote: > > Joe, > > Thank you very much for the comments. Please see below the detailed reply: > > Linda > > From: to..

[IPsec] Re: Need 10 minutes slot at the IPsecme session

Hi, Linda (et al.), I’m not sure I get the whole thing, but (help me if I'm wrong), it seems like the point of this is: a) there are stacks of protocols used for tunnels b) it can be useful to protect just those added protocol layers (which for UDP would include the trailing options). If so, it

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

Hi, Daniel, > On Jan 16, 2023, at 6:37 AM, Daniel Migault wrote: > ... > On Sat, Jan 14, 2023 at 1:01 AM to...@strayalpha.com > <mailto:to...@strayalpha.com> <mailto:to...@strayalpha.com>> wrote: >> ... >> However, that’s the issue. The reasons why what

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

Daniel, > On Jan 13, 2023, at 8:33 PM, Daniel Migault wrote: > > f not, to better understand, do we have an example of a packet that cannot be > processed if the MTU is set to tunMAP but that can be processed if the MTU is > set to EMTU_R. As per intarea-tunnels, MTU is a highly overloaded

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

concerns. > > Yours, > Daniel > > On Sun, Jan 8, 2023 at 11:45 AM to...@strayalpha.com > <mailto:to...@strayalpha.com> <mailto:to...@strayalpha.com>> wrote: >> Hi, Daniel, >> >> The abstract clearly states a goal that is not achievable (of

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

fferent visions and >> tried to highlight this also. >> >> One big clarification in my point of view is that the previous version >> confused MTU with MAP. >> >> We are happy to get your feedback. >> >> Yours, >> Daniel >> >

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

On Oct 31, 2022, at 11:07 AM, Daniel Migault wrote: > >> - the tunnel has two DIFFERENT relevant MTUs >> the egress reassembly MTU (EMTU_R), which is the only thing >> that should drive the “tunnel MTU” >> >> the tunnel MTU, which the ingress needs to know for sou

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

> On Oct 31, 2022, at 1:23 PM, Tero Kivinen wrote: > > to...@strayalpha.com writes: >> >> What SHOULD happen in IPsec is that the SPI should have an MTU >> (being a link) and the *router* where packets are forwarded into the >> tunnel should determine when pac

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

See below in-line. > On Oct 31, 2022, at 8:53 AM, Daniel Migault wrote: > > > > On Mon, Oct 31, 2022 at 11:25 AM to...@strayalpha.com > <mailto:to...@strayalpha.com> <mailto:to...@strayalpha.com>> wrote: >> HI, Tero, et al,, >> >> Thank

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

On Oct 31, 2022, at 5:17 AM, Michael Richardson wrote: > > > The other question is whether or not we can just leverage RFC9268 to do this. > This is a recent 6man innovation. You’d need to decide whether you are trying to fix IPv4 or IPv6 (this doc relies on IPv4) and whether you think RFC9268

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

used here are ambiguous - “downstream” of a tunnel means traffic as it leaves the egress, but “downstream’ of the ingress could mean either that or the tunnel path itself (both are downstream). > On Oct 31, 2022, at 4:18 AM, Tero Kivinen wrote: > > to...@strayalpha.com writes: >>

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

t; it explains why this isn’t useful. Joe > > Yours, > Daniel — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > > > > > > > > > On Sun, Oct 30, 2022 at 6:04 PM to...@strayalpha.com > <mailto:to...@strayalpha.com> <mailto:to...

Re: [IPsec] draft-liu-ipsecme-ikev2-mtu-dect early TSVAREA review

There are some issues with the doc: - abstract has a typo, doc uses ’node’ where it should use ‘router’ for on-path frag, etc - discussion should to be more specific with respect to RFCs 1122, 792, and 4821 - the overall problem is assumed but never clearly defined I agre

Re: [IPsec] [Tsv-art] I-D Action: draft-ietf-ipsecme-rfc8229bis-07.txt

This looks good, though I might suggest adding the update to security considerations to the document change summary in Sec 1.1. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Jun 3, 2022, at 9:02 AM, Valery Smyslov wrote: > > Hi, > > we published a new version, which sh

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

See below... — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Jun 2, 2022, at 8:03 AM, Valery Smyslov wrote: > > HI Joe, > > On Jun 2, 2022, at 12:55 AM, Valery Smyslov > wrote: >> >> HI Joe, >> >> one more question: >> >> You can also not

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

See below... — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Jun 1, 2022, at 9:53 AM, Valery Smyslov wrote: > > Hi Joe, > > From: secdir [mailto:secdir-boun...@ietf.org > <mailto:secdir-boun...@ietf.org>] On Behalf Of to...@strayalpha.com > &

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

On Jun 2, 2022, at 12:55 AM, Valery Smyslov wrote: > > HI Joe, > > one more question: > > You can also note that there are ways to mitigate the cost of > resync when > this implementation is tightly coupled with TCP, e.g., by ensuring > every Nth > IPsec packet

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

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

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

Some notes below... > On May 31, 2022, at 4:14 AM, Valery Smyslov wrote: > > Hi Joe, > > From: to...@strayalpha.com [mailto:to...@strayalpha.com] > Sent: Monday, May 30, 2022 10:57 PM > To: Tero Kivinen > Cc: Valery Smyslov; Christian Huitema; sec...@ietf.or

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

On May 31, 2022, at 8:29 AM, Tero Kivinen wrote: > > I think we should tear down the TCP stream immediately if we detect > that length bytes can't be correct. If that’s the case, then you’re opening up this approach to a much lower bar to attacks. It would be significantly more useful to find

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

On May 30, 2022, at 12:25 PM, Tero Kivinen wrote: > > I think we need to add text explaining how to detect when the TCP > length framing gets messed up by attacks, and how to recover (i.e., > close down the TCP channel and recreate the TCP channel). The impact of RSTs can be limited for this pu

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

... > On May 30, 2022, at 9:21 AM, Valery Smyslov wrote: > > > From: to...@strayalpha.com <mailto:to...@strayalpha.com> > [mailto:to...@strayalpha.com <mailto:to...@strayalpha.com>] > Sent: Monday, May 30, 2022 7:00 PM > To: Valery Smyslov > Cc: Christian

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

Christian, > > From: to...@strayalpha.com <mailto:to...@strayalpha.com> > [mailto:to...@strayalpha.com <mailto:to...@strayalpha.com>] > Sent: Monday, May 30, 2022 6:21 PM > To: Christian Huitema > Cc: Valery Smyslov; sec...@ietf.org <mailto:sec...@ietf.org>;

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

> On May 30, 2022, at 8:00 AM, Christian Huitema wrote: > > The bar against TCP injection attacks might be lower than you think. An > attacker that sees the traffic can easily inject TCP packet with sequence > number that fit in the flow control window and are ahead of what the actual > sender

Re: [IPsec] [Last-Call] [Tsv-art] Tsvart last call review of draft-ietf-ipsecme-rfc8229bis-06

Hi, Valery, Thanks - I will confirm when the update is posted so this can be closed out. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On May 24, 2022, at 4:27 AM, Valery Smyslov wrote: > > Hi Joe, > > please see inline. > > Regards, >

Re: [IPsec] [Tsv-art] Tsvart last call review of draft-ietf-ipsecme-rfc8229bis-06

Hi Valery, Notes below. Joe > On May 23, 2022, at 4:53 AM, Valery Smyslov wrote: > > Hi Joseph, > > thank for your review, much appreciated. More inline. > >> Reviewer: Joseph Touch >> Review result: Ready with Issues >> >> This document has been reviewed as part of the transport area revie