[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Summary of issues
Folks,
I reviewed the SHIM6 mailing list archives since IETF 66 in July, and
generated a summary of what I felt were the issues raised on the
shim6 document set, and the comments made in response. I hope this is
of some assistance.
Again, I'd like to request that you please review these documents and
come prepared to the WG meeting with your review comments.
regards,
Geoff
----------------------------------------------------------------
Issues
1. Jim Bound - IPSEC
"the locator pair in the IP header are not used for IPsec
encyrpt and decrypt as is done today according to IPsec. This is
using out-of-bound signals to set up IPsec and was specifically
rejected as a method for IPsec when defining the IPsec architecture
back in 1995 at IETF Danvers meeting. In addition this type of use of
IPsec should be verified and supported by the IPsec WG within the IETF."
Response:
There is no "out of band" signalling used to set up IPSEC in a
SHIM6 context. As the shim sits below the IPSEC processing phase in
the IP stack IPSEC uses conventional IPSEC-related setup and does not
rely on any form of out-of-band signalling. The IPSEC SA relies on
the ULID pair.
2. Jim Bound - Use of HBA
"Recommendation: For now remove HBA and the use of ULID security
specifying HBA and leave it as work to be completed that avoids this
IPR problem with CGA. Suggestion is to simply embed ULIDs within the
data payload with new option and secure all communications at least
for now for IP layer communcatiions with IPsec encryption based on
locator pair. Separating the movement of Shim6 to proposed standard
from the issue of ULID security using HBA
Response:
IPR issues relating to CGA have been clarified to the Working Group
Jari Arkko: In the IPR discussion a specific problem that was
raised was the generality of the defensive clause. As you may
remember, the statement was formulated such that from Ericsson point
of view anyone can use this technology for free. But only as long as
the user do not sue Ericsson for some of his own patents (on any field).
I plan to ask if our IPR department could agree on changing this
such that it only applies to IETF technology. Based on a private
discussion with Jim, this removes at least his concern.
If there were other IPR related concerns, let me know so that I
can let our IPR department know. I plan to talk to them later this
week. In particular, input from the various groups that are working
with Shim6 implementations for open source would be valuable, if they
have issues that prevent implementation.
Jari Arkko: I'm sending this e-mail just to let people know that
when I talked to the Ericsson IPR department there were OK with the
proposed change that I described on the list earlier. They will
update the IPR declaration at the IETF site once its clear that the
WG is otherwise happy with the protocol set.
3. Jim Bound - modular ULID Security
"treat the security of ULIDs as module (abstractly speaking) for
SHIM6 where the user or implementer can plug in different
solutions. We would abstract out ULID processing for security so
that multiple solutions could be used. Each solution would be its
own IETF draft specification and IETF discussion with close
collaboration with the IETF Security Area"
Response:
Marcelo Bagnulo: A solution based on IPSec requires either pre
shared keys between all the nodes in the internet or certificates for
all the nodes of the internet. This is a huge deployment obstacle. So
this solution does present this problem and needs to be taken into
account when evaluating different solutions. A solution that does not
requires this would require less deployment effort. Of course this is
not the only (or even most important) consideration when evaluating
alternative solutions but it is indeed an important element.
The base protocol has support for multiple security mechanisms
including CGA and HBA but it leaves the door open to other solutions
to protect the binding [...] we need to standarize at least one of
the security mechanisms, if not the shim6 protocol is simply useless.
The current draft proposes two mechanisms the CGA and the HBAs (and
implementation can implement just one of them).
Jari Arkko: 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.
Marcelo Bagnulo: 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)
Ah, I missed that. This may be enough.
4. Marcelo Bagnulo - multiple hash support in the CGAs
"As I understood most folks thought that it was a good idea to
enable multiple hash support in the CGAs and that the proposed
approach for supporting it was acceptable.
In order to support multiple public Key algorithms, it is enough
to define a CGA extension that contains the public key algorithm used
(and maybe the correspondent key) and to use it as an input to the
hash, rather than encode in address bits. This is so, because a
downgrading attack using an alternative (weaker) public key function
is no different than an attack based on finding an alternative public
key (using the same algorithm). In order to attack a CGA using an
alternative (weaker) public key algorithm, the attacker needs to find
a CGA parameter data structure which hash output collides with the
target CGA. In order to do that the attacks will probably try with
alternative modifiers rather than try with alternative pubic keys
(since it is cheaper as the modifier can be any value and its
generation is simply adding 1 to the previous value).
So, from this, it results that in order to prevent downgrading
attacks only the hash function needs to be included in the address
itself, and other information (including alternative public key
algorithms) can be included as CGA extensions. So no modifications to
the draft will be made in order to support alternative public key functions.
WG Last Call: 27 September
http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-05.txt
http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-06.txt
Comments on failure-detection - appear to be resolved
proto - request to include examples of locator change
clarification of "BROKEN" in locator Preference Option
failure detection - clarity issues, technical change suggested
We can add in the draft that a locator change is either to add new
locators to the locator set or to remove locators from it.
Am ok with addin additional text for the broken flag since there
is no text describing it... i am willing to include additional text
on the temporary flag, but not sure what to include there though
Resources for SHIM6
http://www.shim6.org/