> On Nov 1, 2018, at 06:03, Tero Kivinen <[email protected]> wrote: > > Scott Fluhrer (sfluhrer) writes: >> My issue with this general idea is backwards compatibility; if we >> issue a transform of type 5 to an old IKEv2 system, it may reject >> the entire exchange with an "unrecognized transform type" error (and >> yes, there are real systems that behave this way). > > That implementation is broken, and needs to be fixed.
Indeed, the WG repeatedly said this is not a valid argument. Let’s bury it for good this time. > That is not true. Section 3.3.3 lists mandatory types, and those > optional types, which are included in that RFC. It does NOT list any > of the future optional types. > > In section 3.3.6 this is explained very clearly: > > If the responder receives a proposal that contains a Transform Type > it does not understand, or a proposal that is missing a mandatory > Transform Type, it MUST consider this proposal unacceptable; however, > other proposals in the same SA payload are processed as usual. > Similarly, if the responder receives a transform that it does not > understand, or one that contains a Transform Attribute it does not > understand, it MUST consider this transform unacceptable; other > transforms with the same Transform Type are processed as usual. This > allows new Transform Types and Transform Attributes to be defined in > the future Agreed. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
