Re: AHbis WG LC: need for source address based selectors

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

Steve and Tero,

Tero wrote:
>> If I undestand correctly Pekka is asking that the document does not
>> say you MUST NOT allow source address based SA selection (I do not
>> thing it currently says so). I assume that if it does not say anything
>> that this is forbidden or even better says that implementation MAY
>> support SA selection based on the SPI and source address, he will be
>> happy.

I would be quite happy if the AHbis allowed source address
based selectors even implicitly.  Right now it has the paranthesized
sentense saying that the particular nominal bit pattern is not
meaningful, thereby implicitly forbidding selecting SA using
only the source address.

Tero wrote:
>> "The SPIs from the reserved range may used different demultiplexing
>> algorithms and use source and/or destination address and/or protocols
>> and/or some other information for the actual demultiplexing. A
>> document describing new reserved SPI number MUST also specify the
>> demultiplexing algorithm used for that specific SPI."

I don't even need this much to be said.  Just removing the
paranthesized sentence would be mostly enough.


Let me reiterate here why source address based selection would
be useful.  Right now SEND carries a public signature key and
other parameters in the AH header, and uses only one AH SA
which extracts the key from the header, checks the validity of
the key either with CGA or against certificates, and verifies
the signature.  I tend to agree with Steve that this is not
really consistent with the IPsec model.

Hence, what I have proposed is to move the key and associated
data from the AH header to a separate extension header that
would precede the AH header in processing order.  In this scheme,
the extension header creates an AH SA on the fly.  (Didn't
SKIP do something like this?)  If CGA is used, the AH SA is
only valid for processing this single packet; if certificates
is used, the lifetime of the SA depends on what the certs and
what the local policy state.

When the AH header is handled, the SA is already there, and
AH just does the "usual thing", in this case checks the
signature.

The problem is really how to find the right SA.  Destination
address is not the answer, since the scheme must work both
with multicast and with unicast.  With multicast only you
perhaps could use a combination of destination and source
addresses, but not with unicast.  In many cases you
don't have any state associated with the destination node,
you are just replying to a multicast message.

You can't really allocate a new SPI in the inline KMP,
since you have only one message, and the destination
selects the SPI values to be used.

Consequently, the only reasonable field to use for selecting
the right SA would be the source address.  Furthermore, that
would be the logical choice, since the public key is directly
related to the source address anyway.

I hope this makes this all clearer.

--Pekka Nikander