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

[to...@strayalpha.com]

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 review team's
>> ongoing effort to review key IETF documents. These comments were written
>> primarily for the transport area directors, but are copied to the document's
>> authors and WG to allow them to address any issues raised and also to the 
>> IETF
>> discussion list for information.
>> 
>> When done at the time of IETF Last Call, the authors should consider this
>> review as part of the last-call comments they receive. Please always CC
>> tsv-...@ietf.org if you reply to or forward this review.
>> 
>> Overall, this document adds useful clarifications to the original RFC on
>> tunneling IPsec over TCP. There are a number of issues that should be 
>> addressed
>> as it proceeds, as noted below. All can be addressed relatively directly 
>> (i.e.,
>> none create new open issues).
>> 
>> General comments:
>> 
>> The document lacks (and would benefit from) a section providing details of 
>> the
>> differences in this update.
> 
> Good point.
> 
> can add the following text at the end of 1.1:
> 
> In particular:
> o The interpretation of the Length field preceding every message is clarified
> o Use of NAT_DETECTION_*_IP notifications is clarified
> o Retransmission behavior is clarified
> o Using cookie and puzzles is described with more detail
> o Error handling is clarified
> o Implications of TCP encapsulation on IPsec SA processing are expanded
> o Interaction of TCP encapsulation with MOBIKE is clarified
> o Section describing interactions with other IKEv2 extensions is added
> o Recommendation for TLS encapsulation include using TLS 1.3
> 
> Is it OK?

Sure; it might also be useful to indicate the section where each is addressed 
in most detail.

>> Figures should include captions.
> 
> I would leave this to RFC Editor (we tried to keep RFC 8229 text when 
> possible,
> and it doesn't have captions too).

The RFC Editor isn’t likely to care. These can be added without changing the 
intent of RFC 8229; in most cases, the caption is fairly obvious from the text.

>> Given the new document adds primarily clarifications, it would be preferable 
>> if
>> the header numbering were not gratuitously modified vs. the original. The new
>> section 2 should be demoted to 1.2 as per the original; this would go a long
>> way to avoiding unnecessary confusion between the two.
> 
> OK, makes sense.
> 
>> Specific suggestions and concerns:
>> 
>> Section 3 clarifies the meaning of the 16-bit length field as including both
>> the message and the message length field. This is counterintuitive and
>> problematic, notably because ESP messages could be up to 65535 bytes long. 
>> This
>> possibility should be addressed (e.g., prohibit tunneling of messages over
>> 65533 bytes).
> 
> This is a a good catch, we'll add this clarification.
> 
>> Section 4.2 claims the length cannot be 0 or 1 bytes; again, this suggests it
>> might have been better to have the length field no include the length itself.
> 
> The design decision that length field includes both the message and the 
> message
> length was made back in 2016 when RFC 8229 was developed to align 
> it with 3GPP’s recommendation. We are not in a position to change this design.

Understood.

>> Regardless, it seems there are other lengths that are equally invalid (isn’t
>> there a min ESP header size? What about the IP packet header inside)? The 
>> true
>> min should be indicated.
> 
> TCP encapsulation is used for IKE too and "NAT keepalive" messages 
> may still be sent by IKE (even they are not needed for TCP), which are 1 byte 
> long.

It might be useful to mention that.

> It's a good question whether empty messages (with Length = 2) are OK.

>> From receiver's point of view following the Postel's rule I'd simply ignore 
>> them 
> and don't tear down TCP...
> 
>> Section 7.1 suggests closing idle TCP connections to clean up resources; this
>> is inconsistent with TCP’s basic premise (don’t clean it up until those
>> resources are used for a new connection). There should be a more direct 
>> reason
>> given for this change.
> 
> If a TCP connection is no more associated with any SA, then it SHOULD be 
> deleted by TCP Originator. In some cases the TCP FIN/ACK messages 
> will not reach the Responder (e.g. due to network problems), 
> so this TCP connection will become an orphan on Responder, 
> since no new traffic will ever be sent over it. 
> We see no reason to waste Responder's resources in this case - this is the 
> reason.
> Note, that this recommendation is MAY, you are free to ignore it.

It might be useful to indicate that the reason is to conserve responder IPsec 
resources, i.e., this is (to TCP) an application consideration, not a TCP one.

> 
>> Section 7.1 me

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

[to...@strayalpha.com]

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,
> Valery.
>  
> From: to...@strayalpha.com <mailto:to...@strayalpha.com> 
> [mailto:to...@strayalpha.com <mailto:to...@strayalpha.com>] 
> Sent: Monday, May 23, 2022 6:14 PM
> To: Valery Smyslov
> Cc: tsv-art; draft-ietf-ipsecme-rfc8229bis@ietf.org 
> <mailto:draft-ietf-ipsecme-rfc8229bis@ietf.org>; ipsec@ietf.org 
> <mailto:ipsec@ietf.org>; last-c...@ietf.org <mailto:last-c...@ietf.org>
> Subject: [***SPAM***] Re: [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  <mailto:s...@elvis.ru>> 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 review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> tsv-...@ietf.org <mailto:tsv-...@ietf.org> if you reply to or forward this 
> review.
> 
> Overall, this document adds useful clarifications to the original RFC on
> tunneling IPsec over TCP. There are a number of issues that should be 
> addressed
> as it proceeds, as noted below. All can be addressed relatively directly 
> (i.e.,
> none create new open issues).
> 
> General comments:
> 
> The document lacks (and would benefit from) a section providing details of the
> differences in this update.
> 
> Good point.
> 
> can add the following text at the end of 1.1:
> 
> In particular:
> o The interpretation of the Length field preceding every message is clarified
> o Use of NAT_DETECTION_*_IP notifications is clarified
> o Retransmission behavior is clarified
> o Using cookie and puzzles is described with more detail
> o Error handling is clarified
> o Implications of TCP encapsulation on IPsec SA processing are expanded
> o Interaction of TCP encapsulation with MOBIKE is clarified
> o Section describing interactions with other IKEv2 extensions is added
> o Recommendation for TLS encapsulation include using TLS 1.3
> 
> Is it OK?
>  
> Sure; it might also be useful to indicate the section where each is addressed 
> in most detail.
>  
>   Done.
>  
>> Figures should include captions.
> 
> I would leave this to RFC Editor (we tried to keep RFC 8229 text when 
> possible,
> and it doesn't have captions too).
>  
> The RFC Editor isn’t likely to care. These can be added without changing the 
> intent of RFC 8229; in most cases, the caption is fairly obvious from the 
> text.
>  
>   I’ve added titles for the figures defining headers and prefix 
> formats 
>   and removed anchors from figures in Appendix B (so they are now 
> “inline”).
>  
>> Given the new document adds primarily clarifications, it would be preferable 
>> if
>> the header numbering were not gratuitously modified vs. the original. The new
>> section 2 should be demoted to 1.2 as per the original; this would go a long
>> way to avoiding unnecessary confusion between the two.
> 
> OK, makes sense.
> 
> 
> Specific suggestions and concerns:
> 
> Section 3 clarifies the meaning of the 16-bit length field as including both
> the message and the message length field. This is counterintuitive and
> problematic, notably because ESP messages could be up to 65535 bytes long. 
> This
> possibility should be addressed (e.g., prohibit tunneling of messages over
> 65533 bytes).
> 
> This is a a good catch, we'll add this clarification.
> 
> 
> Section 4.2 claims the length cannot be 0 or 1 bytes; again, this suggests it
> might have been better to have the length field no include the length itself.
> 
> The design decision that length field includes both the message and the 
> message
> length was made back in 2016 when RFC 8229 was developed to align 
> it with 3GPP’s recommendation. We are not in a position to change this design.
>  
> Understood.
> 
> 

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

[to...@strayalpha.com]

> 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 produced. 


It might be useful to be more specific about the issue. Data injection attacks 
on TCP connections interfere with the IPsec stream in a similar way to IP or 
UDP fragment attacks on IP or UDP tunnels that use fragmentation. 

In all three cases, attackers can corrupt in-transit packets via IP packet 
attacks, which is not possible with an unfragmented IPsec message.

In all three cases, this happens when an injection can overwrite a portion of 
an IPsec message.

Data isn’t injected to the user, though.

Joe




___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

It might be useful to add that most of those injection attacks are similar to 
the kind of attack possible when IPsec is carried inside IP tunnels or UDP 
tunnels when IPsec messages are split across tunnel messages. In those cases, 
the vulnerability depends on the predictability of the fragment identifier, 
which can be much smaller than the predictability of being within the TCP 
receive window sequence space, esp. for long-lived TCP connections.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On May 30, 2022, at 8:28 AM, Valery Smyslov  wrote:
> 
> Hi Joe, 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>; 
> draft-ietf-ipsecme-rfc8229bis@ietf.org 
> <mailto:draft-ietf-ipsecme-rfc8229bis@ietf.org>; ipsec@ietf.org 
> <mailto:ipsec@ietf.org>; last-c...@ietf.org <mailto:last-c...@ietf.org>
> Subject: Re: [Last-Call] Secdir last call review of 
> draft-ietf-ipsecme-rfc8229bis-06
>  
>> On May 30, 2022, at 8:00 AM, Christian Huitema > <mailto:huit...@huitema.net>> 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 produced. 
> 
>  
> It might be useful to be more specific about the issue. Data injection 
> attacks on TCP connections interfere with the IPsec stream in a similar way 
> to IP or UDP fragment attacks on IP or UDP tunnels that use fragmentation. 
>  
> In all three cases, attackers can corrupt in-transit packets via IP packet 
> attacks, which is not possible with an unfragmented IPsec message.
>  
> In all three cases, this happens when an injection can overwrite a portion of 
> an IPsec message.
>  
> Data isn’t injected to the user, though.
>  
>   I suggest we add the following text to the Security considerations:
>  
>  
>  
>TCP data injection attacks have no effect on application data since
>IPsec provides data integrity.  However, they can have some effect,
>mostly as a DoS attack:
>  
>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
>   tear down the TCP connection if the content of the Length field
>   happens to be 0 or 1 (see Section 3)
>  
>o  if the content of an IKE message is altered, then it will be
>   dropped by the receiver; if the dropped message is the IKE request
>   message, then the initiator will tear down the IKE SA after some
>   timeout, since in most cases the request message will not be
>   retransmitted (as advised in Section 6.2) and thus the response
>   will never be received
>  
>o  if an attacker alters the non-ESP marker then IKE packets will be
>   dispatched to ESP and sometimes visa versa, those packets will be
>   dropped
>  
>o  if an attacker modifies TCP-Encapsulated stream prefix or
>   unencrypted IKE messages before IKE SA is established, then in
>   most cases this will result in failure to establish IKE SA, often
>   with false "authentication failed" diagnostics
>  
>An attacker capable of blocking UDP traffic can force peers to use
>TCP encapsulation, thus degrading the performance and making the
>connection more vulnerable to DoS attacks.  Note, that attacker
>capable to modify packets on the wire or to block them can prevent
>peers to communicate regardless of the transport being used.
>  
>  
>  
> (The text is still a draft, I’ve been waiting for Tommy to review it).
>  
> Regards,
> Valery.
>  
>  
> Joe
>  
>  
>  
>  
> -- 
> last-call mailing list
> last-c...@ietf.org <mailto:last-c...@ietf.org>
> https://www.ietf.org/mailman/listinfo/last-call 
> <https://www.ietf.org/mailman/listinfo/last-call>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

...
> 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 Huitema; sec...@ietf.org <mailto:sec...@ietf.org>; 
> draft-ietf-ipsecme-rfc8229bis@ietf.org 
> <mailto:draft-ietf-ipsecme-rfc8229bis@ietf.org>; ipsec@ietf.org 
> <mailto:ipsec@ietf.org>; last-c...@ietf.org <mailto:last-c...@ietf.org>
> Subject: Re: [Last-Call] Secdir last call review of 
> draft-ietf-ipsecme-rfc8229bis-06
>  
> It might be useful to add that most of those injection attacks are similar to 
> the kind of attack possible when IPsec is carried inside IP tunnels or UDP 
> tunnels when IPsec messages are split across tunnel messages. In those cases, 
> the vulnerability depends on the predictability of the fragment identifier, 
> which can be much smaller than the predictability of being within the TCP 
> receive window sequence space, esp. for long-lived TCP connections.
>  
>   Do you mean that fragmented packets will never be re-assembled at 
> receiving end and thus dropped?

Or reassembled with incorrect data, then IPsec will decide they fail 
decryption. Either way, it’s an attack that non-fragmented packets aren’t 
susceptible to.

>  
>   We can add the following sentence after the list in the text below:
>  
>   Note, that data injection attacks are also possible on IP level 
> (e.g. when IP fragmentation is used)
>   resulting in DoS attack even if TCP encapsulation is not used.

The useful addition is that the TCP injection attack is easier to do than the 
IP fragmentation injection attack (or even a GRE fragmentation injection). TCP 
keeps a long receive window open that’s a sitting target for such attacks (the 
first byte to the last byte of the entire window of bytes). IP fragmentation 
does not need to use sequence numbers in order, and even when ti does its 
“target” “window” is only the number of fragment IDs in round trip, which is a 
much smaller attack surface.

Joe___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

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 purpose by recommending RFC5961 for 
these connections.

But if even data injection has the same impact, it’d be much better to see if 
there’s a way to recover “sync” in the byte stream rather than expecting a new 
connection.

Joe

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

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 a way to resync. I don’t have any 
particular suggestions there, except maybe when sync is lost to scan for a 
known byte pattern and try to resync there. If the IPsec then starts to work 
again, you’re set. If not, you keep scanning.

This is the approach ATM used to find cell boundaries.

Is there a reason not to include that as a fallback when such attacks are seen 
as a mitigation to avoid the restart overhead??

Joe___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

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.org; 
> draft-ietf-ipsecme-rfc8229bis@ietf.org; ipsec@ietf.org; last-c...@ietf.org
> Subject: Re: [Last-Call] Secdir last call review of 
> draft-ietf-ipsecme-rfc8229bis-06
>  
> On May 30, 2022, at 12:25 PM, Tero Kivinen  <mailto:kivi...@iki.fi>> 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 purpose by recommending RFC5961 
> for these connections.
>  
>   I’ve added a reference to RFC 5961.
>  
>   Currently the new text in the Security considerations looks like:
>  
>TCP connections are also susceptible to RST and other spoofing
>attacks [RFC4953].  This specification makes IPsec tolerant of sudden
>TCP connection drops, but if an attacker is able to tear down TCP
>connections, IPsec connection's performance can suffer, effectively
>making this a DoS attack.
>  
>TCP data injection attacks have no effect on application data since
>IPsec provides data integrity.  However, they can have some effect,
>mostly as a DoS attack:
>  
>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
>   tear down the TCP connection if the content of the Length field
>   happens to be 0 or 1 (see Section 3)
>  
>o  if the content of an IKE message is altered, then it will be
>   dropped by the receiver; if the dropped message is the IKE request
>   message, then the initiator will tear down the IKE SA after some
>   timeout, since in most cases the request message will not be
>   retransmitted (as advised in Section 6.2) and thus the response
>   will never be received
>  
>o  if an attacker alters the non-ESP marker then IKE packets will be
>   dispatched to ESP and sometimes visa versa, those packets will be
>   dropped
>  
>o  if an attacker modifies TCP-Encapsulated stream prefix or
>   unencrypted IKE messages before IKE SA is established, then in
>   most cases this will result in failure to establish IKE SA, often
>   with false "authentication failed" diagnostics
>  
>[RFC5961] discusses how TCP injection attacks can be mitigated.
>  
>Note, that data injection attacks are also possible on IP level (e.g.
>when IP fragmentation is used) resulting in DoS attack even if TCP
>encapsulation is not used.  On the other hand, TCP injection attacks
>are easier to mount than the IP fragmentation injection attacks, because
>TCP keeps a long receive window open that's a sitting target for such
>attacks.
>  
>An attacker capable of blocking UDP traffic can force peers to use
>TCP encapsulation, thus degrading the performance and making the
>connection more vulnerable to DoS attacks.  Note, that attacker
>capable to modify packets on the wire or to block them can prevent
>peers to communicate regardless of the transport being used.


Overall, that’s good, but….

>  
>  
> But if even data injection has the same impact, it’d be much better to see if 
> there’s a way to recover “sync” in the byte stream rather than expecting a 
> new connection.
>  
>   TCP connections can be closed and re-open – I don’t think this is a 
> big problem if IKE SA survives.

Not huge, but a lot bigger than native IPsec - and that’s the issue. See my 
other note about re-sync.

>   The real problem is when IKE SA (and all Child SAs) is teared down 
> as result of attack.
>   This can happen when IKE message is corrupted or incorrectly parsed 
> as a result of data injection attack.
>  
>   Currently the draft says that there is no need to retransmit the 
> request message in case of TCP (with SHOULD NOT).
>   We can add a note that implementations MAY retransmit messages to 
> mitigate a possibility of data injection attacks.
>  
>   Regards,
>   Valery.
>  
>  
>  
> Joe
>  
> -- 
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

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 scan, but that in some cases such a scan can be 
more 
efficient in than starting a new connection, although it does mean that 
such 
an attack may be more likely moving forward (note: restarting a 
connection
might provide useful information to an attacker, where continuing may 
hide
the impact of such an attack too, so resync has cons and pros).

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 starts at the beginning of a new TCP packet.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Jun 1, 2022, at 6:15 AM, Valery Smyslov  wrote:
> 
> 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)
>>> will be this random data
>>> 
>>> So:
>>> - with probability 1-1/2^32 all subsequent packets will be treated
>>> as ESP packets, and not as IKE packets (the probability for
>>> non-ESP marker to be non-zero)
>>> - the "SPIs "of these "ESP" packets will be random, so unless the
>>> receiver has very large number of active ESP SAs (say > 2^31),
>>> these "SPIs" will be unknown to the receiver
>>> 
>>> So, it's enough to check whether the SPI of the received ESP packet is 
>>> valid.
>>> This is a simple check that will work in most cases. If an SPI is invalid,
>>> the receiver should immediately reset TCP connection. I think that
>>> receiving a single invalid SPI is enough reason to do this, since
>>> this should never happen in normal conditions.
>> 
>> The draft already covers most of these cases in section 7.1:
>> 
>>   If either the TCP Originator or TCP
>>   Responder detects corruption on a connection that was started with a
>>   valid stream prefix, it SHOULD close the TCP connection.  The
>>   connection can be determined to be corrupted if there are too many
>>   subsequent messages that cannot be parsed as valid IKE messages or
>>   ESP messages with known SPIs, or if the authentication check for an
>>   ESP message with a known SPI fails.  Implementations SHOULD NOT tear
>>   down a connection if only a single ESP message has an unknown SPI,
>>   since the SPI databases may be momentarily out of sync.
>> 
>> We might want to expand the "detects corruption" a bit more, i.e., add
>> explict sentence about length fields getting messed up and need for
>> resync causing this corruption.
> 
> I don't think this is needed. The corruption of Length field can only be 
> determined
> indirectly by receiving invalid SPIs or failures to validate ICV, which are 
> already mentioned.
> 
>> Also as was pointed out by you in the other parts of the thread, there
>> is a way to resync, by searching known spi + sequence number in window
>> from the stream (this gives us about 56 bits to check against). After
>> we find such candidate framing, we can check the length before, and
>> validate ICV. If ICV matches, we know this is valid packet, and we can
>> resync, of not, we can either search again, or simply close the TCP
>> stream.
>> 
>> On the other hand I do not think resync is needed in practice, but I
>> do not want to forbid by mandating that peer must tear down TCP
>> immediately when it receives unknown SPI, or has mismach between IKE
>> SA header length field and TCP stream length fields.
>> 
>> So I think we should add text explaining that implementation can try
>> to resync by by searching valid length + SPI + Sequence number + ICV
>> combination from the stream, or it can simply restart the TCP stream
>> (if it is TCP Originator, or it can close the TCP stream if it is TCP
>> Responder).
>> 
>> Then we can add text in security consideration section explaining this
>> bit more (you already had candidate text for that).
> 
> 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 look like:
> 
>   If an attacker successfully mounts an injection attack on a TCP
>   connection encapsulating IPsec traffic, and a Length field in the TCP
>   stream is changed as a result of this attack, then the receiver in
>   most cases will not be able to correctly identify the boundaries of
>   the following packets in the stream, because it will try to parse an
>   

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

[to...@strayalpha.com]

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 starts at the beginning of a new TCP packet.
>  
>  How would this help? Can you please elaborate?

If every 4th IPsec packet is always aligned to the TCP segment data start, then 
resync checks could be simple and rapid - check only the first bytes for a 
known pattern.

That makes resync happen with lower overhead, i.e., rather than searching the 
whole payload.

Joe___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

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 
> <mailto:to...@strayalpha.com>
> Sent: Wednesday, June 01, 2022 5:43 PM
> To: Valery Smyslov
> Cc: draft-ietf-ipsecme-rfc8229bis@ietf.org 
> <mailto:draft-ietf-ipsecme-rfc8229bis@ietf.org>; sec...@ietf.org 
> <mailto:sec...@ietf.org>; ipsec@ietf.org <mailto:ipsec@ietf.org>; 
> last-c...@ietf.org <mailto:last-c...@ietf.org>
> Subject: Re: [secdir] [Last-Call] [IPsec] 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
>  
>   Already in the draft.
>  
> - indicate that there IS a way to avoid that hit by re-syncing
>   the sync requires a scan, but that in some cases such a scan can be 
> more 
>   efficient in than starting a new connection, although it does mean 
> that such 
>   an attack may be more likely moving forward (note: restarting a 
> connection
>   might provide useful information to an attacker, where continuing 
> may hide
>   the impact of such an attack too, so resync has cons and pros).
>  
>   I’ve added some text about the possibility of a resync. 
>   About information for an attacker – if we talk about off-the-path 
> attacker,
>   then in general it is unaware of the results of its attack, it may 
>   only guess them indirectly. And since resync will take some time 
> and 
>   thus introduce some delay, that may be visible to attacker, I’m not 
> sure 
>   which method is preferable in this context – everything depends on
>   specific conditions for the attacker.

Yes, but a connection restart is much more potentially visible to an external 
viewer than a few IPsec packets inside the transfer being discarded.

Joe___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

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 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 starts at the beginning of a new TCP packet.
>>  
>>  How would this help? Can you please elaborate?
>  
> If every 4th IPsec packet is always aligned to the TCP segment data start, 
> then resync checks could be simple and rapid - check only the first bytes for 
> a known pattern.
>  
> That makes resync happen with lower overhead, i.e., rather than searching the 
> whole payload.
>  
>   Interesting idea, but how the receiving node would know that 
> sending node employs this method?

They don’t need to. Basically the receiver should “check a few places until it 
wants to give up”. There’s no rule that resync must be exhaustive, but if it 
succeeds, it averts the need for a new connection.

>   And, in my understanding some middleboxes can re-arrange TCP 
> segments, merging and splitting them,

They DO this, as do some offloading devices, sometimes in ways that break TCP. 
But that doesn’t matter here - again, at the receiver, it either works or it 
doesn’t.

>   so the beginning of IPsec packet may still appear in the middle of 
> TCP segment (the same can happen
>   with retransmissions, but I guess you assume that sending TCP/IP 
> stack would take care in this case, but it adds complexity).

Retransmissions don’t need to realign; the sender can just do this on first 
transmission. It’s just an optimization that helps the receiver potentially 
resync faster or not need to give up on resync as quickly.

>  
>  So, I think that the idea is interesting, but the additional 
> complexity and unreliability makes it not so attractive.

It doesn’t need to be reliable to be useful, as per above.

>  
>   Regards,
>   Valery.
>  
> Joe
> -- 
> last-call mailing list
> last-c...@ietf.org 
> https://www.ietf.org/mailman/listinfo/last-call 
> 
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

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 should address comments
> received during IETF LC and directorate reviews.
> 
> Many thanks for very helpful reviews!
> 
> Regards,
> Tommy & Valery.
> 
>> -Original Message-
>> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of 
>> internet-dra...@ietf.org
>> Sent: Friday, June 03, 2022 6:49 PM
>> To: i-d-annou...@ietf.org
>> Cc: ipsec@ietf.org
>> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc8229bis-07.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the IP Security Maintenance and Extensions WG 
>> of the IETF.
>> 
>>Title   : TCP Encapsulation of IKE and IPsec Packets
>>Authors : Tommy Pauly
>>  Valery Smyslov
>>  Filename: draft-ietf-ipsecme-rfc8229bis-07.txt
>>  Pages   : 34
>>  Date: 2022-06-03
>> 
>> Abstract:
>>   This document describes a method to transport Internet Key Exchange
>>   Protocol (IKE) and IPsec packets over a TCP connection for traversing
>>   network middleboxes that may block IKE negotiation over UDP.  This
>>   method, referred to as "TCP encapsulation", involves sending both IKE
>>   packets for Security Association establishment and Encapsulating
>>   Security Payload (ESP) packets over a TCP connection.  This method is
>>   intended to be used as a fallback option when IKE cannot be
>>   negotiated over UDP.
>> 
>>   TCP encapsulation for IKE and IPsec was defined in RFC 8229.  This
>>   document updates the specification for TCP encapsulation by including
>>   additional clarifications obtained during implementation and
>>   deployment of this method.  This documents obsoletes RFC 8229.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc8229bis/
>> 
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-rfc8229bis-07
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc8229bis-07
>> 
>> 
>> Internet-Drafts are also available by rsync at 
>> rsync.ietf.org::internet-drafts
>> 
>> 
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
> 
> ___
> Tsv-art mailing list
> tsv-...@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

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 agree with Michael Richardson’s post of 8-16-22 on a few points:
1) it is premature for a TSV ART review of this document
I’m not actually sure that TSV review is relevant, as tunneling 
is more an INTDIR issue (on which I do not sit),
though I’m probably at least as appropriate a reviewer on 
tunnel issues
2) this discussion is confusing as to both aspects and terminology of 
tunneling
I encourage those interested review draft-intarea-tunnels - 
while expired 
(I’m getting back to it), it remains definitive in the IETF 
AFAICT

The stated point of this work, rephrased, is to have the IPsec tunnel egress 
tell the IPsec tunnel ingress that the (next hop) link MTU out of the egress 
(i.e., after traffic exits the tunnel) is too small for the packets the egress 
node tries to forward.

So it tells the tunnel ingress that the egress link MTU is too small. But that 
MTU is of the origin packet (not the tunnel packet, which includes the source 
packet as a paylaad), which the tunnel ingress has no control over.

I.e., this isn’t a signal from the egress to the ingress about the tunnel 
(path) MTU. Even if it were, then the tunnel ingress would be sending more 
fragments (at the tunnel ingress by source-fragmented at the outer header); it 
can’t change the MTU of the origin packets it happens to receive — that happens 
at the packet origin, which can be upstream of the ingress, or at a minimum is 
outside the scope of IPsec (even if the ingress and packet origin are a the 
same node).

What exactly is this a solution for?

Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

> On Oct 30, 2022, at 6:33 PM, Daniel Migault  wrote:
> 
> Thanks Joe for the feedback. I responded inline to your questions. 
> 
> To the main question: what is this a solution for ? It is a solution to avoid 
> an ingress security gateway to become overloaded by de-fragmenting packets.

We need to get terms clarified. The IPsec tunnel Ingres encapsulates source 
fragments. The IPsec tunnel egress defragments.

> The main idea is that the ingress security gateway informs the egress 
> security gateway that fragmentation is occurring  with an indication of the 
> maximum size of the packet.

The ingress does source fragmentation as needed. The egress might know which 
fragments got through, but that assumes a PLPMTU discovery mechanism (where the 
source tries different fragment sizes), which isn’t what you’ve described. But 
either way, this tells you the size of the packets that get through the tunnel.

Note: there are two different sizes that are relevant here: the path MTU of the 
tunnel (the source has to fragment packets into chunks no larger than that or 
they won’t traverse the tunnel) and the egress reassembly size (EMTU_R of the 
egress). The only packet the egress can’t reassemble is one that exceeds EMTU_R.

However, the doc talks about the MTU downstream of the egress, which is (best 
case) the path MTU from the egress to the destination or (worst case) just the 
link MTU of the next hop out of the egress. Nothing the ingress does has any 
bearing on packets that traverse that path - once they leave the egress, 
they’re just the origin packets.

> In the best case scenario, the security gateway informs the source node to 
> reduce the size of the inner packet with an ICP PTB packet for example. 

How? It can’t send an ICMP because it doesn’t have *the* packet causing the 
problem to “reflect” back to the source. The ingress may not know who the 
source is (there may be thousands or millions of sources). So which source?

I still don’t see a useful mechanism here - I recommend you take a look further 
at the tunnels draft (which explains all of this in detail.

> I do believe that the communication between the ingress and egress security 
> gateway is in scope of IPsec.

It definitely is, but the questions here are many:
- what information do you think the egress has that is useful to share 
with the ingress?
- what would the ingress do what that information if thad it?

> My perception is that it is an ICMP PTB with the assurance the message is 
> received.

ICMP PTBs can (and do, in some cases) happen on the tunnel and go back to the 
tunnel ingress. 

> What I think you mean is outside the scope of IPsec is sending an ICMP PTB 
> message (in the case of a remote node) or changing the MTU directly in the 
> case the source node and security gateway are the same entity. What is 
> unclear to me is whether the current design violates anything or why it 
> wouldn't work.

First, it won’t work when they’re not the same node. Second, it won’t work 
unless you know which source on that node to signal - which you don’t. 

> Then, do you have any recommendations to achieve what we are trying to 
> achieve ?

Again, please read the tunnels draft; 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...@strayalpha.com>> wrote:
>> There are some issues with the doc:
>>  - abstract has a typo, doc uses ’node’ where it should use ‘router’ for 
>> on-path frag, etc
> easy to fix. 
>>  - discussion should to be more specific with respect to RFCs 1122, 792, 
>> and 4821
> Apart from 1122, we have all these references. If you still have in mind what 
> needs to be more specific that would help. From the text below, it seems the 
> use of egress / ingress should be used as opposed to upstream, downstream. Is 
> that what you mean ?
>>  - the overall problem is assumed but never clearly defined
>> 
> In the intro we have the following text that intends to capture that we are 
> willing to avoid reassembling.
> 
>   IPv4 packets are often fragmentable with
>their DF bit set to 0.  In this case, as described in [RFC0792], when
>a packet size exceeds its MTU, the node fragments the incoming packet
>in multiple fragments.  The inconvenient is that the receiving
>security gateway will have to re-assembled the multiple fragments to
>rebuilt an ESP packet before being able to apply the IPsec
>decapsulation. 
> 
> 
>> I agree with Michael Richardson’s post of 8-16-22 on a few points:
>>  1) it is premature for a TSV ART review of this document
&

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

[to...@strayalpha.com]

HI, Tero, et al,,

Thanks for the clarification; I now understand that what you really are seeking 
is PLPMTUD for IPsec, but somehow using on-path fragmentation as a signal. 
That’s a mistake, IMO, largely because it serves only IPv4.

To the authors, again please see intarea-tunnels. The terms 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:
>>In the best case scenario, the security gateway informs the source node to
>>reduce the size of the inner packet with an ICP PTB packet for example. 
>> 
>> How? It can’t send an ICMP because it doesn’t have *the* packet causing the
>> problem to “reflect” back to the source. The ingress may not know who the
>> source is (there may be thousands or millions of sources). So which source?
> 
> The normal case to do that is that IPsec SGW keeps track of the size
> of packets that are ok, and which are too big based on the information
> it receives. I.e., it might have received unsecured ICMP PTB message
> from the network for its own Child SA, but only knows the SPI of the
> Child SA, not who was the original sender. So it keeps track that for
> this SPI the ESP packets cannot be larger than xxx bytes.
> 
> Next time it receives a packet from the source and when it is
> encrypting it, it will verify that it will fit the size set for that
> Child SA, and if it is too big, it will generate ICMP PTB for that
> specific packet.
> 
> IPsec gateways have been doing that for years, and this has been
> described in the RFC4301 section 8.2.1.

That would happen because the tunnel packet caused PTB. This case is described 
in intarea-tunnels 4.3.2. The way in which IPsec gets it wrong (IMO) is 
described in Section 4.3.1 and is related to RFC 3884, e.g., by subsuming the 
functions of a router inside the IPsec mechanism, rather than operating 
strictly as a tunnel, which should be represented as a link - and *links do not 
send ICMP messages.

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 packets that want to enter that link are too big - at which point, per RFC 
1812, the *router* should be sending the ICMP.

> My understanding is that this draft (which I have not yet properly
> read) is solving the situation where the tunnel does not get ICMP PTB
> messages as they are forwarding packets with DF bit set to 0, and then
> the receiving end will see extra fragmentation happening for the
> packets. Then the receiving end will simulate the ICMP PTB by sending
> authenticated IKEv2 notification that tells the sending end that his
> packets got fragmented.

The only reason the packet would have been too big at the receiver is if it 
were to exceed the receiver’s reassembly buffer. That’s not what’s happening 
here.

It seems like there’s confusion about the fact that the source can somehow 
avoid fragmentation of the tunneled packets. That can’t happen - see 
intarea-tunnels Sec 3.6.3. Source fragmentation can and must still occur. The 
receiver should never send PTBs for 64-byte IPv4 packets (or 1280B IPv6).

Further, on-path fragmentation for IPv4 has been warned against (the source has 
to rate-limit to avoid ID reuse during expected reordering, per RFC 6864).

> Now the sending end can do similar processing of this information that
> it does for unauthenticated ICMP PTB messages received for ESP
> packets. 

Receiving a fragment isn’t a PTB event, though, as noted above. 

> -- 
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

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 headers will help or hurt the 
chances of your IPv6 packets getting through a net.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

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,,
>> 
>> Thanks for the clarification; I now understand that what you really are 
>> seeking is PLPMTUD for IPsec, but somehow using on-path fragmentation as a 
>> signal. That’s a mistake, IMO, largely because it serves only IPv4.
>> 
> My understanding is that IPv6 performs fragmentation at the source, in which 
> case, the receiving gateway does not need to defragment. 

Both IPv4 and IPv6 use source fragmentation, which cannot be avoided for 
tunnels (see intarea-tunnels).

There are two sources (please review intarea-tunnels); please explain more 
clearly which one you mean.

The original source of the packet (outside the tunnel) does source 
fragmentation. This doesn’t impact the IPsec egress (please - not “receiving 
gateway” - that could refer to ANY router on the path, either outside the 
tunnel or inside the tunnel; note that it does NOT actually refer to the IPsec 
egress because IPsec could be implemented as “bump in the wire” and its 
endpoints might not be gateways at all).

But *so does the IPsec ingress*. It fragments the tunnel packets (again, see 
intarea-tunnels). It is THOSE packets the IPsec egress reassembles. 

> Our problem is only happening with IPv4 when an on-path router fragments and 
> the receiving security gateway needs to re-fragment.

You should already stop using on-path *TUNNEL* hop refragmentation (again, 
router here is ambiguous).

The “receiving gateway” is the IPsec egress of this traffic. Why do you keep 
saying it needs to refragment? It *reassembles* the tunnel fragments (but it 
has to - source fragmentation is always possible and will always need to be 
supported).

> We explicitly mention in the introduction that what we have is not a  PLPMTUD 
> for IPsec.

Understood. But here’s the issue:

- the end-to-end path can and should be using PLPMTUD
having your system find a way for IPsec ingresses to generate 
*more* ICMP PTBs is not a solution,
as you already note (because they’re untrusted, dropped, or not 
generated in the first place)

- 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 source 
fragmentation, but is NOT relevant to the
origin MTU upstream of the ingress

Tunnels fragment and reassemble. There is no way to avoid that or to tune to 
that, *if you implement your tunnel properly, that fact is and needs to be 
invisible* to the endpoints.

Or do you want your endpoints sending 48B payloads when you transit ATM links 
too (they do still exist)?

> Our understanding is that we are closer to ICMP-like than a PLPMTUD. Maybe a 
> PLPMTUD can be built on top of it, but we would like to avoid taking that 
> path for now. 

Please review intarea-tunnels. Signals inside the tunnel are not always 
appropriate to relay outside the tunnel.

But the really confusing part here is that you admit that ICMP doesn’t work, 
but you’re designing a system to detect (the wrong) info to send in ICMPs.

Joe

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

> 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 packets that want to enter that link
>> are too big - at which point, per RFC 1812, the *router* should be
>> sending the ICMP.
> 
> This is what the RFC4301 describes if I understood your description
> correctly. ...
> 
> So I think IPsec is still doing everything correctly.

For PTBs received along the path, then yes.

There are a few different cases here:
- the reassembled tunnel packet is decrypted, decapsulated, and inside 
is an IPv4 DF=1 that exceeds the next-hop MTU
at which point the IPsec tunnel egress router sends ICMP PTB 
based on that decapsulated (origin) packet (or not)

- the tunnel hops generated a PTB to the IPsec ingress, which changes 
its MTU
and the router at that ingress router sends PTBs back on 
subsequent packets if they receive IPv4 DF=1 that exceed that MTU

- the egress reassembly fails because tunnel packet exceeds EMTU_R at 
the egress
there’s no ICMP for this message, however

The PTBs of the tunnel (middle case) change the fragment size emitted from the 
ingress  (EMTU_S) accordingly, but it would not cause the tunnel to fail.

But note that the tunnel MTU is not its path MTU; it is the EMTU_R of the 
tunnel. Other packets CAN traverse it. So the only MTU the IPsec ingress should 
ever send back in a PTB would be EMTU_R of the tunnel.

This document tries to get around the fact that ICMP has no “packet bigger than 
I’d like” signal.

(Yes, I realize this means tunnels need to do frag/reassemly and this is 
expensive; the reason is explained in intarea-tunnels. If you’re talking about 
tunnels then reading that doc is a prerequisite - at least to my further 
involvement)

Until that signal exists, calculating it and relaying it is not useful. Even 
then, using ICMP to do this makes no sense, esp. given the entire mechanism 
assumes ICMP doesn’t work over the tunnel path.

Joe

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

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 source 
>> fragmentation, but is NOT relevant to the
>>  origin MTU upstream of the ingress
>> 
> Will read the draft - but we believe that is better to generate one IPsec 
> packet for every inner IP packet as opposed to two. This is why we are 
> proposing to adjust the MTU so the outer packet matches the limit of the 
> EMTU_R - and fragmentation be avoided.

That doc explains why this is effort isn’t useful. As I noted to Tero, there’s 
no ICMP message that says “bigger than I’d like”. PTB means “packets larger 
than this will be dropped”. That’s not what’s going on here, so it’s the wrong 
message to support.

There is no message that supports what you’re trying to do - perhaps because 
there can’t and shouldn’t be.

Joe___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

Hi, Daniel,

The abstract clearly states a goal that is not achievable (of avoiding 
reassembly). The best way to avoid the impact of mid-tunnel fragmentation is to 
use IPv4 as a tunnel header the way that IPv6 would be - with DF=1. However, 
even so, the egress always needs to handle reasssembly as long as there is even 
source fragmentation.

I appreciate what you WANT to do - but again, it is not possible. You have two 
behaviors - either use inner fragmentation (which won’t work for transit 
traffic where IPv4 DF=1 or any IPv6) or reduce the tunnel MTU.

But the tunnel MTU is defined by EMTU_R of the tunnel egress, not EMTU_S of the 
tunnel ingress. If you reduce the tunnel MTU, you’re just going to end up 
black-holing packets arriving at the tunnel ingress.

Two important points: the tunnel ingress is NOT the one that should ever send 
PTB back; that’s the job of the router where/if that tunnel ingress resides; 
second, you cannot claim to get around an ICMP black hole situation by creating 
a new ICMP black hole situation.

The rest of the document is rife with further errors, e.g.:

The last sentence of the abstract is incomprehensible. 

In the intro, the claims about IPv4 ID are incorrect. As noted in RFC6864, 
speed is not the issue but rather the expected reordering. Additionally, 
there’s already a timeout, so there is no requirement for indefinitely kept 
state. Further, given source fragmentation, such issues are irrelevant.

DF=1 leads to black holing ONLY in the absence of PLPMTUD, which is the 
appropriate solution for IPsec tunnels anyway. Note that even if DF=0, 
black-holing could still occur if the Tunnel Transit packet exceeds the tunnel 
egress EMTU_R.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Jan 4, 2023, at 7:21 PM, Daniel Migault  wrote:
> 
> Hi Joe, 
> 
> We are waiting for your feedback, but I just want to check we have the same 
> understanding and that we will have a feed back.
>   
> We would like to understand if the terminology used in the document is 
> aligned with the one of intarea-tunnels and if we agree that intarea-tunnels 
> and IPsec have different perspectives on handling fragmentation. I do not see 
> what we are proposing very different from what IPsec has been doing for 
> years.  
> 
> I also think that everything is explained in the introduction (2 text pages), 
> so you do not have to read the full document. The document is available here:
> https://datatracker.ietf.org/doc/draft-liu-ipsecme-ikev2-mtu-dect/
> 
> Yours, 
> Daniel
> 
> On Sat, Nov 26, 2022 at 9:25 AM Daniel Migault  <mailto:mglt.i...@gmail.com>> wrote:
>> Hi Joe, 
>> 
>> So  we just published an update of our draft. We try to catch up the 
>> complete idea in the introduction - to avoid reading the complete draft. I 
>> think we partly aligned with the tunnel document. The current version only 
>> describe the security gateway as a node and does not split it between a 
>> outer and an interface. I think for the remaining of the document we are 
>> taking the exact terminology from the tunnel draft.
>> 
>> We believe that IKEv2 and the tunnel document have different 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
>> 
>> On Mon, Oct 31, 2022 at 5:32 PM to...@strayalpha.com 
>> <mailto:to...@strayalpha.com> > <mailto:to...@strayalpha.com>> wrote:
>>> On Oct 31, 2022, at 11:07 AM, Daniel Migault >> <mailto:mglt.i...@gmail.com>> 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 source 
>>>>> fragmentation, but is NOT relevant to the
>>>>>   origin MTU upstream of the ingress
>>>>> 
>>>> Will read the draft - but we believe that is better to generate one IPsec 
>>>> packet for every inner IP packet as opposed to two. This is why we are 
>>>> proposing to adjust the MTU so the outer packet matches the limit of the 
>>>> EMTU_R - and fragmentation be avoided.
>>> 
>>> That doc explains why this is effort isn’t useful. As I noted to Tero, 
>>> there’s no ICMP message that says “bigger than I’d like”. PTB means 
>>> “packets larger than this will be dropped”. That’s not what’s going on 
>>> here, so it’s the wrong messa

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

[to...@strayalpha.com]

Hi, Daniel,

> On Jan 13, 2023, at 2:12 PM, Daniel Migault  wrote:
> 
> Hi Joe,
> 
> Thanks for the comment. There are some terminologies we were not using 
> properly, so thank you for the clarification. Please find inline our 
> clarification and implementation of your 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 avoiding 
>> reassembly). The best way to avoid the impact of mid-tunnel fragmentation is 
>> to use IPv4 as a tunnel header the way that IPv6 would be - with DF=1. 
>> However, even so, the egress always needs to handle reasssembly as long as 
>> there is even source fragmentation.
>  
> I understand the comment as our goal is interpreted to avoid reassembling 
> operations to happen completely. This would mean that reassembly could even 
> not be implemented. 
> This is not our intention. Reassembly happens the same way it happens today. 
> The only thing we do is that the egress node notify the ingress node that 
> reassembly is happening. The ingress node may or may not take any action to 
> prevent reassembly to happen with the next packets being tunneled over the 
> IPsec tunnel. In that sense "avoid" needs to be understood as reducing the 
> number of occurrences the reassembly operation happens.  
> 
> We may agree the best way to avoid mid tunnel fragmentation is to set DF=1. 
> But in our case we cannot meet this condition. 
> The current text in the abstract is
> 
> OLD:
> This document considers an ingress and an egress security gateway connected 
> over an IPv4 network.
> The Tunnel Link Packet have their Don't Fragment (DF) set to 0.
> 
> Does the text below is clearer to say:
> 
> NEW:
> This document considers an ingress and an egress security gateway connected 
> over a IPv4 network with the Tunnel Link Packet Don't Fragment (DF) set to 0.

That is better English, but still technically ill-advised. Any solution that 
requires IPv4 DF=0 then requires generation of unique IDs that don’t wrap in 
ways that could cause mis-reassembly per RFC 6864.

> The introduction mentions the rationals on why we cannot rely on setting 
> DF=1. Typically some routers do not check the MTU and ignore the packet 
> without returning a ICMP PTB error and in many deployments the ICMP PTB -if 
> sent - is blocked and is not received. This prohibits the use of DF=1 with 
> IPv4. 

You have described the reason why PLPMTUD exists, which is not a rationale for 
continuing to use on-path IPv4 fragmentation.

>> 
>> I appreciate what you WANT to do - but again, it is not possible. You have 
>> two behaviors - either use inner fragmentation (which won’t work for transit 
>> traffic where IPv4 DF=1 or any IPv6) or reduce the tunnel MTU.
>> 
>> But the tunnel MTU is defined by EMTU_R of the tunnel egress, not EMTU_S of 
>> the tunnel ingress. If you reduce the tunnel MTU, you’re just going to end 
>> up black-holing packets arriving at the tunnel ingress.
>> 
>  ok. I misunderstood tunnel MTU and that tunnel MTU is EMTU_R, this is not 
> what we are changing. What we had written might be confusing. 
> When I said EMTU_R I was considering the router only without any 
> consideration of the tunnel.  From the terminology section of intarea-tunnel 
> I did not read EMTU_R applies to a tunnel environment, and considered this to 
> be the MTU associated to the interface for incoming packet to the router.
> 
> Here is what we actually meant:
> 
> 
> We are ensuring that packet that are encapsulated by the Ingress interface do 
> not exceed the tunnel MAP.  My understanding is  that the tunnel MAP is the 
> largest IP packet the source can send,  that will not be fragmented by the 
> network between the Ingress and egress interface. As it is not fragmented, 
> fragments will not be reassembled.

Please review intarea-tunnels.

Setting Ingress send size to MAP doesn’t avoid source fragmentation, which thus 
doesn’t avoid reassembly. It just sets the size of each fragment to avoid 
on-path fragmentation - which avoids the need for DF=0. So setting DF=0 is 
exactly what you don’t need.

> To do so, we set the MTU of the router associated with the Ingress interface 
> is set to the tunnel MAP. This corresponds to set tunMTU =tunMAP  Figure 11 
> of intarea. 
> 
> Suppose an IP packet is sent by the source and meets that router. 
> * The packet has DF=1. If it is larger than that MTU (= tunMAP), the packet 
> is discarded and an ICMP PTB message is sent back to the source. The source 
> will proc

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

[to...@strayalpha.com]

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 term.

Tunnels relay packets that exceed their tunMAP but not their tunMTU (EMTU_R - 
headers) using source fragmentation all the time.

However, that’s the issue. The reasons why what you’re trying to do isn’t 
useful is already covered in detail in intarea-tunnels - and why not to do it 
using IPv4 DF=0 in rfc6864.

It’s not useful to have an email exchange rehashing that content message by 
message.

Joe___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

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 you’re trying to do isn’t 
>> useful is already covered in detail in intarea-tunnels - and why not to do 
>> it using IPv4 DF=0 in rfc6864. 
>> 
> rfc6864 provides requirements of IP ID. DF=1 for inner and outer packet 
> prevents using IP ID, but as mentioned DF=1 for outer is not possible in our 
> case

I’ve already explained how it is.

> and I am not sure we can enforce DF=1 in the inner packet as well. 

You don’t need to.

> Our proposal results in limiting fragmentation as well - when possible - and 
> as such makes these requirements easier to meet.

Any new use of DF=0 is directly against rfc6864 recommendations 
Additionally, you’re creating a new mechanism that is relevant only for IPv4; 
IPv6 has no DF=0 equivalent. That’s against current general advise not to focus 
on new IPv4-only approaches.

>> It’s not useful to have an email exchange rehashing that content message by 
>> message.
>> 
> The conversation has been clarifying to us - at least regarding the 
> terminology and we believe the document has improved, so that has been 
> somewhat useful and we thank you for these feedbacks.
> While DF=1 is the recommended way, it is not an option for us - unless proven 
> otherwise.

DF=0 requires you to enforce that you don’t reuse IDs during potential 
reassembly overlap, which requires knowing that AND setting the appropriate 
reassembly timeout at the receiver. You don’t do that so you don’t have a 
solution, IMO.

And DF=0 works only for IPv4, so that’s another reason you don’t have a 
solution. Any solution for IP should work for IPv6 first; if it also works (or 
doesn’t) for IPv4, that ought to be secondary at this point.

> **With DF=0**, we do measure some significant performance improvement by 
> using our proposal and so far, I have been able to see any reasons for not 
> doing it.

Improved performance only because you don’t check or enforce ID uniqueness. 

> If such reasons exist, it would be clarifying to explicitly mention them 
> explicitly (to me and the WG) so these could be considered..  

I have been explicit about these problems before as well.

Joe___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[to...@strayalpha.com]

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...@strayalpha.com <mailto:to...@strayalpha.com> 
> mailto:to...@strayalpha.com>> 
> Sent: Thursday, October 31, 2024 12:31 AM
> To: Linda Dunbar  <mailto:linda.dun...@futurewei.com>>
> Cc: Tero Kivinen mailto:kivi...@iki.fi>>; Yoav Nir 
> mailto:ynir.i...@gmail.com>>; ipsec@ietf.org 
> <mailto:ipsec@ietf.org>
> Subject: Re: [IPsec] 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:
> there are stacks of protocols used for tunnels
> [Linda] “Stacks of Protocols”: do you mean layers of encapsulation headers on 
> the data plane?  Yes.
>  
> it can be useful to protect just those added protocol layers (which for UDP 
> would include the trailing options).
> [Linda] Correct. The document targets the protection of encapsulation headers 
> rather than the entire packet payload.
>  
> If so, it might be useful to make that more clear. It may also be useful to 
> provide some info as to why protecting just these added layers is a win; a 
> lot of times, the per-packet operations can be as significant as the per-byte 
> operations, and removing some of the bytes - even the majority - might not be 
> a big win. It’d be useful to provide evidence if so.
> [Linda] the payload is already encrypted. By focusing only on the 
> encapsulation headers, the authentication process is lighter, requiring fewer 
> computational resources. This is particularly advantageous in high-speed 
> networks or resource-constrained environments.

[JT] The assertion is clear, but evidence is what I suggested would be useful. 
Many security protocols have hardware acceleration that may not be able to 
identify and isolate headers (and, for UDP options, trailers). In other cases, 
per-packet operations may dominate vs. per byte costs. In either case, it would 
be useful to provide some evidence of this claim.

> It does seem unclear as to what layer this operates, though. If it’s IP, it 
> seems inappropriate to expect it to parse down into the transport metadata.
>  
> I would instead expect it the other way around - e.g., a variant of TCP-AO or 
> UDP AUTH option that would cover the IP pseudoheader and transport headers, 
> but not the transport payload. That could easily be defined as an 
> endpoint-coordinated variant of either of those protocols, which don’t have 
> in-band key/parameter negotiation for authentication anyway.
> [Linda] This is not a transport-layer solution like TCP-AO or UDP AUTH, which 
> would typically cover both the transport header and payload. Instead, it 
> complements these by providing lightweight authentication of the 
> encapsulation headers used in overlay or tunnel scenarios.

[JT] OSI protocol layer identifications are relative, not absolute (they always 
have been; we’ve been aware of this since the late 1990s). When TCP or UDP is 
used to encapsulate IP, those protocols act as link layers to that IP packet. 
TCP-AO and UDP AUTH both cover their layer’s endpoint association, which 
includes the TCP/UDP header/trailer and also the IP pseudoheader. In both 
cases, parameters are determined outside the protocol. Either could be defined 
with a parameter indicating the payload would be excluded from the 
authentication computation, just as TCP-AO-NAT (rfc 6978) does by excluding the 
source IP address and TCP port.

Joe

>  
> Joe
>  
> —
> Dr. Joe Touch, temporal epistemologist
> www.strayalpha.com <http://www.strayalpha.com/>
> 
> 
> On Oct 28, 2024, at 4:39 PM, Linda Dunbar  <mailto:linda.dun...@futurewei.com>> wrote:
>  
> Joe,
>  
> The primary scenario for the proposed authentication method is from 
> draft-ietf-rtgwg-multi-segment-sdwan
> where an additional header (GENEVE Encapsulation [RFC8926]) is added to the 
> encrypted payload to steer packets through underlay networks. In these 
> scenarios, the underlay network edge nodes do not decrypt and re-encrypt the 
> payloads. The header information is used for optimizing packet forwarding in 
> underlay networks and, therefore, resides outside the IPsec ESP header.
>  
> It was pointed out that UDP option header can also use this proposed approach.
>  
> We would like more feedback from the IPsecme community. 
>  
> Thanks, Linda
> From: Joe Touch mailto:to...@strayalpha.com>> 
> Sent: Monday, October 28, 2024 1:26 PM
> To: Linda Dunbar  <mailto:linda.dun...@

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

[to...@strayalpha.com]

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 might be useful to make that more clear. It may also be useful to 
provide some info as to why protecting just these added layers is a win; a lot 
of times, the per-packet operations can be as significant as the per-byte 
operations, and removing some of the bytes - even the majority - might not be a 
big win. It’d be useful to provide evidence if so.

It does seem unclear as to what layer this operates, though. If it’s IP, it 
seems inappropriate to expect it to parse down into the transport metadata.

I would instead expect it the other way around - e.g., a variant of TCP-AO or 
UDP AUTH option that would cover the IP pseudoheader and transport headers, but 
not the transport payload. That could easily be defined as an 
endpoint-coordinated variant of either of those protocols, which don’t have 
in-band key/parameter negotiation for authentication anyway.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Oct 28, 2024, at 4:39 PM, Linda Dunbar  wrote:
> 
> Joe,
>  
> The primary scenario for the proposed authentication method is from 
> draft-ietf-rtgwg-multi-segment-sdwan
> where an additional header (GENEVE Encapsulation [RFC8926]) is added to the 
> encrypted payload to steer packets through underlay networks. In these 
> scenarios, the underlay network edge nodes do not decrypt and re-encrypt the 
> payloads. The header information is used for optimizing packet forwarding in 
> underlay networks and, therefore, resides outside the IPsec ESP header.
>  
> It was pointed out that UDP option header can also use this proposed approach.
>  
> We would like more feedback from the IPsecme community. 
>  
> Thanks, Linda
> From: Joe Touch mailto:to...@strayalpha.com>> 
> Sent: Monday, October 28, 2024 1:26 PM
> To: Linda Dunbar  >
> Cc: Tero Kivinen mailto:kivi...@iki.fi>>; Yoav Nir 
> mailto:ynir.i...@gmail.com>>; ipsec@ietf.org 
> 
> Subject: Re: [IPsec] Need 10 minutes slot at the IPsecme session
>  
> Do you mean UDP?
> 
> 
> On Oct 28, 2024, at 1:20 PM, Linda Dunbar  > wrote:
> 
>  
> IPsecme Chairs, 
>  
> We would like a 10minutes slot at the IPsecme session in IETF 121 to discuss 
> this draft:
> https://datatracker.ietf.org/doc/draft-dunbar-secdispatch-ligthtweight-authenticate/
>  
> This document describes lightweight authentication methods to prevent 
> malicious actors tampering with the IP encapsulation headers or metadata 
> carried by the UPD Option Header.
>  
> We revised the draft to address comments and suggestion during the offline 
> discussion at IETF120. Would like to get more feedback from the IPsecme group 
> of the revision.
>  
> Thank you. 
>  
> Linda
>  
> ___
> IPsec mailing list -- ipsec@ietf.org 
> To unsubscribe send an email to ipsec-le...@ietf.org 
> 
___
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org