After some edits from Tero, here’s a proposed set of question for RFC 5996 implementers:
- Which of the IKEv2 exchanges you support:
- IKE_SA_INIT (includes support for SA, KE, Ni, Nr payloads)
- IKE_AUTH (includes support for SK, IDi, IDr, AUTH, TSi, TSr
payloads)
- CREATE_CHILD_SA
- INFORMATIONAL
- Which of the IKEv2 payloads your implementation supports
- CERT Certificate
- CERTREQ Certificate Request
- CP Configuration
- D Delete
- EAP Extensible Authentication
- N Notify
- V Vendor ID
- Which of the following processing semantics does your implementation support
(y/n):
- Can your implementation create a new child SAs with the
CREATE_CHILD_SA exchange?:
- Can your implementation rekey an IKE SAs with the CREATE_CHILD_SA
Exchange?:
- Can your implementation rekey a Child SAs with the CREATE_CHILD_SA
Exchange?:
- Does your implementation support the INFORMATIONAL exchange?
- Which of the IKEv2 authentication methods you support
- PKIX Certificates as specified in section 4
- Shared key authentication as specified in section 4
- Mixed authentication, where responder uses Certificates and
initiator uses shared key
-- Which of the usage scenarios does your implementation support (s1.1.1,
s1.1.2, and s1.1.3):
- What evidence do you have that your implementation can interoperate with
other implementations?
- In your opinion, are there unused features in the RFC that greatly increase
implementation complexity?
- Errata was filed against RFC 5996 and has been included in
https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/; are
any of the incorporated errata problematic for your implementation?
Additional information (optional):
spt
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
