Jen Linkova <[email protected]> wrote: >> "Upon completing an IKE negotiation, an IPsec peer wishing to >> ascertain the viability of the path for ESP packets MAY initiate an >> ESP Echo Request packet to the other peer. The ESP Echo Request packet >> MAY be encrypted. If encrypted, it SHOULD utilize an SPI value >> previously negotiated through IKE and set the Next Header value to 59 >> (No Next Header). The receiving IPsec peer, having established ESP >> through IKE, MAY issue an ESP Echo Response. When replying to an >> encrypted ESP Echo Request, the ESP Echo Response MUST be encrypted >> and utilize the corresponding negotiated SPI."
> As I'm not really an IPsec expert, I'm not sure I understand how it
> would work. Let's say a device A sends an ESP echo request packet
> using an existing negotiated SPI. Then it receives an ESP packet back,
> and that packet uses the negotiated SPI and has the next header set to
> no next header. How would that device A differentiate between: - an
It's just that the two negotiated SPIs have no relationship.
Some systems know that they are related, but in general 4301 says that kind
of thing belongs up in the key manager.
My opinion (also as a new co-author) is that we should not attempt to support
echo request/reply for existing SAs.
--
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
