Paul Hoffman writes:
> Ditto for Proposal #2: is there a good reason for you to not have
> included an INTEG transform?
Proposal #2 is the combined mode cipher, thus it cannot have INTEG
other than none, and I though we agreed that it would be better to
leave the whole INTEG transform out in those cases (in section 3.3):
Combined-mode ciphers include both
integrity and encryption in a single encryption algorithm, and MUST
either offer no integrity algorithm or a single integrity algorithm
of "none", with no integrity algorithm being the RECOMMENDED method.
> This begs the related question: given that there is no MUST or
> should for what goes into a Proposal, what does an ESP proposal that
> only has an ENCR and INTEG in it mean with respect to what is being
> proposed for ESN? What does an ESP proposal that has only an ENCR
> and ESN in it mean with respect to what is being proposed for INTEG?
> I see no MUSTs or SHOULDs answering this.
As already pointed out that would be incorrect proposal, but I would
expect lots of the implementations will actually accept it and assume
it means the same thing as ESN=0.
So complient implementation cannot send such proposals. If complient
implementations receives such proposal it should either return error
or assume ESN=0. This is because RFC4306 said in 3.3.3:
A proposal MAY
omit the optional types if the only value for them it will accept is
NONE.
and implementations assumed NONE == 0 == No Extended Sequence Numbers,
meaning if No Extended Sequence Numbers were to be proposed, that
transform could be left out.
As this was confusing that was the reason ESN text was clarified a bit
(i.e. added the paragraph after ESN section in IKEv2bis) and there is
more about it in the RFC4718 section 4.4.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
