Valery Smyslov writes:
> >> And this not the only contradiction between RFC5996 and RFC4945 -
> >> the latter requires ID_IPV*_ADDR to match source IP address of IKE
> >> packet by default, while the former explicitely allows not to do it
> >> in any case.
> >
> > RFC4945 requires that implementations "MUST be capable of verifying"
> > the ID_IPV*_ADDR and IP-address of the packet. RFC5996 says that IKEv2
> > does not require such check. There is no contradiction there.
> 
> RFC4945 requires (MUST) this check to be done by default, treats mismatch as
> an error and allows (MAY) to skip this check only for interoperability 
> purpose.
> Probably not contradiction, but some inconsistency, in my opinion.

Not really inconsistency, it just means that the RFC4945 profile
requires more features than what is required in IKEv2 in general (i.e.
to be able to do the check, and that check is on by default). So
RFC4945 is bit more strict than RFC5996. RFC4945 is IPsec PKI profile
document so it is intended to limit things more than the basic IKEv2.

If someone writes some IPsec XXX Profile document that might add some
other restrictions, for example such profile might require that 4096
bit RAW RSA keys must be used for all authentication for that XXX
environment. This is again more strict than RFC5996 and there is no
contradiction or inconsistency there.

There are RFC5996 implementations which do not need to implement
RFC4945. 

> > Perhaps adding reference to the RFC4945 at the end of section 3.5.
> > Identification Payloads in the RFC5996bis?
> 
> Yes, and some explanation text about inconsistencies between the approaches
> to match ID to certificate.

No. I do not think we need such text. RFC5996 text is for general
IKEv2 implementation. RFC4945 text is only for those implementations
which support that RFC, not for all IKEv2 implementations. RFC4945 is
supposed to be stricter than RFC5996.

If there is case where RFC4945 requires operations which are not
allowed by RFC5996 then we do have inconsistancy.
-- 
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to