Thanks Tero. I agree with your additional observations on the pros of taking this approach for a simpler and shorter WESP negotiation. Furthermore, your point regarding undesirable behavior using a multiple proposals approach with WESP is well noted.
The notification method for WESP negotiation has already been added to the updated draft we submitted last week and unless someone raises additional points on why this may not work, we can leave it as it stands. Thanks, - Ken >-----Original Message----- >From: Tero Kivinen [mailto:kivi...@iki.fi] >Sent: Monday, May 04, 2009 4:49 AM >To: Grewal, Ken >Cc: ipsec@ietf.org >Subject: [IPsec] Issue #90: Shorter WESP negotiation > >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). >-- >kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
