$Id: draft-ietf-shim6-hba-04-rev.txt,v 1.1 2007/11/24 21:57:16 ekr Exp $
The basic goal of this draft is to securely bind together multiple
IPv6 addresses that belong to the same multihomed host. This allows
rerouting of traffic without worrying that you're being redirected
to an attacker. The technique that's used is to use a hash of the
permitted prefixes in the low order bits of the v6 address.
For me, the big unanswered question is why this is a good general
approach. Far preferable, IMO, would be to simply to cryptographically
sign the prefix list using some key bound to the association.
Section 8.1 describes exactly such a mechanism using CGA. This
mechanism has the following advantages:
(1) A more standard style mechanism.
(2) Not tied to SHA-1.
(3) Superior attacker/defender dynamics by increasing the
key size (note that this doesn't help with CGA, but it
would with other approaches). By contrast, this
scheme has an attacker/defender work factor spread of 2^59.
(4) Can add new prefixes in real-time.
As far as I can tell, the only real rationale for this scheme
as opposed to one like I describe above is performance. S 3.3
reads:
Fourth, performance considerations as described in [17] motivated the
usage of a hash based approach as oposed to a public key based
approach based on pure Cryptographic Generated Addresses (CGA), in
order to avoid imposing the performance of public key operations for
every communication in multihomed environments. The HBA appraoch
presented in this document presents a cheaper alternative that is
attractive to many common usage cases. Note that the HBA approach
and the CGA approaches are not mutually exclusive and that it is
possible to generate addresses that are both CGA and HBA providing
the benefits of both approaches if needed.
This is extremely unconvincing. You don't need to impose the
performance of public key operations for "every communication."
Rather, one pair of public key operations is required for each
notification of the prefix set. Unless you are experiencing a truly
amazing amount of address churn, this will be fairly rare, and the
receiving node can simply cache the current prefix list. If that's not
possible for some reason, it's a deficiency in the existing protocols
and is easily fixed. Is there any evidence at all that this is too
expensive in real systems?
Given the flexibility advantages of signature-key based approaches,
the fact that these mechanisms appear to already exist, the advantages
of having only one security mechansim, and the dubious value of the
performance advantages of this mechanism, IMO the IETF would be better
served by not advancing this document at this time. It can always be
resurrected if clear evidence emerges that signature-based approaches
represent a real bottleneck.
DETAILED COMMENTS (unfixed from my review of -01)
S 6.
I wouldn't say "leftmost" or "rightmost". MSB and LSB are superior
terms for SHA-1.
Why are three collisions a boundary here in step 6.4. Have you
analyzed the chance of this happening? Why not just continue
until you're out of collision bits.
-Ekr
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf