Antony Antony <[email protected]> wrote: >> In the original proposal it was clear, as the reserved SPI values were >> used. Am I missing anything?
> For a minimal use case it may work; however, for more generic use
> cases, such as sending multiple requests simultaneously from multiple
> applications, would it work? How would ESP Ping responses correlate to
> multiple instances sending ESP Ping from a sender? I feel the document
> might need to define a specific payload format. This format would help
> us correlate responses with their respective requests, the ESP ping ID
> and sequnce number proposed in
I think we should define something for SPI=7/8.
(I'm not actually certain we should use two SPI numbers. There are pluses
and minuses here)
I think that the problem ESP PING for a negotiated SA is rather a different
problem, and that while we might re-use the packet format, I think it's a
significantly more complicated. (Because it does more)
I think that something with proto=59 might be right, but there are
other choices, and I think that it might turn out that we are actually
defining some kind of ESP-dead-peer-detection mechanism. That we should
simply have the kernel report receipt of PING/discard packets (on SA #1234)
to the IKE daemon, and let it do the correlation.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
