Re: Security Module for shim6 or hip really

[Jari Arkko <jari.arkko@piuha.net>]

Iljitsch van Beijnum wrote:

> On 19-jul-2006, at 16:19, Bound, Jim wrote:
>
>> A suggestion proposed at the Montreal IETF SHIM6 WG meeting was to 
>> treat
>> the security of ULIDs as module (abstractly speaking) for SHIM6 where
>> the user or implementer can plug in different solutions.
>
>
> Right.
>
> This is attractive in some ways, but it does require us to come up 
> with an interface for exchanging this information between the shim 
> layer and the different providers of security. How would that work?

Three notes:

First, it is customary to require a mandatory to implement
security mechanism for IETF specs. Without this, there will be very
little interoperability. But it doesn't rule out pluggable security
mechanisms, just that one of them has to be mandatory.

Second, I believe the specs already support the idea of multiple
mechanisms; the -hba draft allows either HBA, CGA, or HBA/CGA
addresses. However, I can not see a mandatory to implement
(or any other comformance statement) in the draft. Perhaps this
should be added.

Third, I think adding new mechanisms is harder than merely
designing an interface. An extension spec for an alternate
security mechanism, describing impact to Shim6 control
signaling, payload protection, security considerations, etc.
I am sure we can do it, but I am not sure if we need to
develop anything new today to support such extensions.
Even if we did, it is not clear to me that, say, TLS and IPsec
based mechanisms would be able to use the same interface.
But one question: do we have a capability negotiation of
the used security mechanism in the current protocol?
Adding this may be prudent.

--Jari