Hi all,
>
> That implementation is broken, and needs to be fixed.
What's the procedure on this? Is there a need to publish a document or
some test vectors that all implementations can validate against?
Personally, it is more logical to introduce new transform types for
QSKEs, but one of my concerns is how can we guarantee that all broken
implementations are fixed?
Consider the following simplified proposal:
SA Payload
|
+--- Proposal #1 ( Proto ID = IKE(1), SPI size = 0,
| | 6 transforms)
+-- Transform ENCR ( Name = ENCR_AES_CBC )
| +-- Attribute ( Key Length = 256 )
+-- Transform PRF ( Name = PRF_HMAC_SHA2_512 )
+-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 )
+-- Transform D-H ( Name = Curve25519 )
+-- Transform QSKE1 ( Name = Foobar )
+-- Transform QSKE2 ( Name = Zappa )
At the moment, some broken implementations may abort the exchange
entirely and in some way, this helps as we may want to establish a
connection with a broken implementation. On the other hand, there
could be other implementations that ignore both QSKE1 and QSKE2 and
return a response as if there is an implicit second proposal:
|
+--- Proposal #2 ( Proto ID = IKE(1), SPI size = 0,
| 4 transforms)
|
+-- Transform ENCR ( Name = ENCR_AES_CBC )
| +-- Attribute ( Key Length = 256 )
+-- Transform PRF ( Name = PRF_HMAC_SHA2_512 )
+-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 )
+-- Transform D-H ( Name = Curve25519 )
So more complex checks will be required to cater for all broken cases.
I have no idea what response we will get from other broken
implementations.
Or alternatively, do we have to rely on another Notification payload
to check for potential backward compatibility issues?
I think it would be great to also get some thoughts from VPN
manufacturers on this point.
> 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.
>
> I.e., the intention is that if there is transform type you do not
> understand you skip whole proposal, but STILL PROCESS rest of the
> proposals normally, i.e., this allows backward compatiblity.
>
Yes, this is how it should behave.
Cheers,
CJ
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
