Grewal, Ken writes: > In the current traffic visibility draft, we indicate that WESP can be > negotiated via IKEv2 using a new protocol identifier. > Charlie Kaufman suggested that it may be plausible to use a notification > method along the lines of USE_TRANSPORT_MODE in RFC 4306, where the type of > transport is negotiated independently of the cryptographic parameters. > > Pros: Shorted negotiation using notifications.
For pros you can also put down "automatic fallback to normal ESP if other end does not support WESP". There is no guarantee that other end will properly fall back to other protocol if protocol identifier is used when negotiating WESP, but responder MUST ignore unrecognized status notification types. There is no specified requirement for IKEv2 implementation to support multiple proposal substructures, thus trying to propose ESP-NULL or WESP-NULL might not work (i.e. implementation can only check first the most preferred proposal and ignore the others). The current RFC does not specify how many proposals implementations should check, and at least some implementations do have some kind limit for number of proposals they check (and that limit might even be 1). -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
