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

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

Stephen Kent wrote:
>> Since we are using PK crypto, we also need the possibility for 
>> selecting the SA based solely on the source address.  In fact, for
>> our fixed SPI, the destination address does not have any role, not
>> even whether the destination address is unicast or multicast.

> It sounds like SEND would like to use the AH format, but has a 
> processing model that is not aligned with the way IPsec uses SAs in 
> general.

Right now, yes indeed.  With the proposed change of moving the
public key to a separate extension header, thereby generating
a one-message "inline" KMP, not really, IMHO.

> We had extensive discussion in this WG about demuxing for inbound
> IPsec traffic after the MSEC folks expressed concern about the 
> current process last fall. The demuxing spec has been very stable for
> several YEARS; we tweaked it very slightly for MSEC, after
> considerable debate and analysis, to accommodate SSM.

I sort of followed that discussion, but not very closely.  I can't
claim that I would remember all the details.

> Your proposed change represents yet another bit of complexity for an
> IPsec implementation and I question whether the WG ought to agree to
> such a change at this late date.

I am sorry of the late date.  My only excuse is that SEND has
only recently progressed to a level where we are able to
comment AHbis.

Returning to the real question, I actually claim that the
proposed change would simplify a typical implementation.
According to the current spec, you may have to handle unicast
and multicast addresses differently, and you have to implement
the restriction that the "use source address, don't use
destination address" is forbidden.

Remember, IPv6 ND requires multicast, and hence a conforming
implementation MUST implement the multicast demultiplexing
algorithm anyway.

One way of implementing the current specification is to
implement the two nominal bits into the SAD database, and
all the code required to check the source address, the
destionation address, both, or neither.  After that, one
would *add* the code to forbid the bit pattern indicating
that only the source address check sould be made.

 From an implementation point of view, these restrictions
are additional complexity, and removing them would reduce
complexity.  But maybe you had some other type of complexity
in mind?

Actually, the minimum change to AHbis would be to remove
the paranthesized sentence "(There is no current requirement
to support SA mapping based on the source address but not the
destination address, thus one of the possible four values is
not meaningful.)"  Adding some clarifying text, indicating
that if only the source address is used for demultiplexing,
then whether the destination address is multicast or unicast
does not matter, would be helpful, too.

--Pekka Nikander