[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Notify SPI field specifications
Hi. In the San Diego bakeoff I was studying the RFCs with somebody
and we noticed some strange descriptions for the Notify SPI field.
Here's what RFC 2408 says in section "3.14 Notification Payload":
> o SPI (variable length) - Security Parameter Index. The receiving
> entity's SPI. The use of the SPI field is described in section
And RFC 2407 says in section "4.6.3.1 RESPONDER-LIFETIME":
> o SPI - set to the two ISAKMP cookies or to the sender's inbound
> IPSEC SP
I find the latter description quite clear. But the one in RFC 2408
is quite unclear and possibly even contradictory to it. In the RFC 2408
description, what is "receiving entity"? Is it the one receiving the
notification? If so, then which SPI does it have? The incoming? If so,
the RFC 2408 proposes the use of Notification-Receivers-Inbound-SPI
i.e. Notification-Senders-Outbound-SPI which is not the same as
Notification-Senders-Inbound-SPI in RFC 2407...
Even if I'm to ignore the SPI value for phase 1, the specifications
also disagree, I think, upon the value that should be put to the SPI
field for phase 1. Again from the same sections in these two RFCs:
RFC 2408:
> The Protocol Identifier, in this case, is
> ISAKMP and the SPI value is 0 because the cookie pair in the ISAKMP
> Header identifies the ISAKMP SA.
RFC 2407:
> o SPI - set to the two ISAKMP cookies or to the sender's inbound
> IPSEC SPI
That is, RFC 2408 proposes zero and RFC 2407 the cookies.
Also, I found it quite funny for RFC 2407 to say in the description of
the SPI Size field that "If the SPI Size is non-zero, the content of
the SPI field MUST be ignored.". If the SPI Size is zero, I am expected
to check the SPI field! If I understood this right, the specification
should have said perhaps "The SPI Size and SPI fields MUST be ignored
for phase 1."
Jari Arkko
Ericsson