On Fri, Jul 28, 2023 at 11:36 AM Tero Kivinen <kivi...@iki.fi> wrote:
> Sequence number is just 32-bit sequence number (always present, can > be used when correlating request to response). > Antony yesterday suggested to me that some stateful firewalls/middleboxes might be happier if these numbers started from 1 and counted upwards. I'm not sure if this is possible though - the first time you run the esping (or espping?) binary it can send packets 1, 2, 3, ...42, but the second time you run it, how will it know that it needs to start with 42? By comparison, ping uses both an ID and a sequence number, and the sequence number is scoped to a particular ID. We could do something like this by deciding that the first 16 bits of the ESP sequence number are the ID and the bottom 16 bits are the sequence number. Payload data/padding is can be any length in reqeust and is always > copied in response, i.e., it can be used as nonce/cookie to make sure > nobody out side the path can fake responses. > > There would not be padding or next header fields, and the ICV field > would be zero length. > SGTM. Hopefully middleboxes won't be too unfriendly to this. Generally I would assume that when a middlebox looks at ESP packets, other than the sequence number, it's not going to look into the payload because it will assume it's encrypted. If we want to implement Antony's suggestion of doing this ping on real ESP sessions as well, then that would require the ping packet to be valid ESP, i.e., properly encrypted, with valid padding and next header fields. In that case, maybe we can use Next Header 59 per RFC 4303 section 2.6?
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
