Hi Jari, El 30/07/2006, a las 23:58, Jari Arkko escribió:
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.
i think you are rightmoreover, i think it would be interesting to understand how the protocol would behave, if for instance, one end supports only HBA and the other end only supports CGA (or other two different security mechanisms) do we need to include some form of security mechanisms declaration at the establishment?
i guess we could simply not ack those locators validated with non supported security mechanisms, but the current draft only acccept to ack or not ack the update message as a whole (not per locator)
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.
well, what we have in the current protocol is that the Locator List Option Format has a one octet of Verification Method per locator included in the option, so that we can specify the mechanism used to validate each of the locators (currently only HBA and CGA methods are defined in the draft)
however, it is not obvious at this point what a host can do if the validation method for the locators is not supported. One option is to not ack the whole update. The other option is to not use those locators for sending packets (the reception of packet is done solely based on the context tag, so it doesn't matter which source locator is used). But this leaves no chance for the other end to use a different validation mechanism to validate those locators.
perhaps one option would be to include something like the Locator List Option in the ack message where the receiver of the update message can ack each locator separately and also specify the reason why it doesn't ack a given locator (including a code for validation method not supported)
Regards, marcelo
--Jari