Hash-Based Addresses (HBA)
draft-ietf-shim6-hba-05

[Ballot comment]
Based on Gen-ART Review by Spencer Dawkins.

  The document says:
  >
  > For multihoming applications, it is also relevant to verify if a
  > given HBA address belongs to a certain HBA set.  An HBA set is
  > identified by a CGA Parameter Data structure that contains a Multi-
  > Prefix Extension.  So, it is then needed to verify if an HBA belongs
  > ...
  >
  What party is performing the verification? Please clarify.

[Ballot discuss]
This discuss is on the Security Considerations section:

The entire discussion is about how the end points determine the valid sets. There is no discussion about how a firewall might react to a dos where the attacker was sending bogus initial Protocol Structures to create false state.

[Ballot comment]
I support Dan's/Peter's discuss, but will let Dan hold it.

Also, On the typo side there seems to have been a generic miss in references to other sections inside the doc (basically it seems it always references the
section with an offset of 2). For example section 6:

1. Multi-Prefix Extension generation.  Generate the Multi-Prefix
      Extension with the format defined in section 3.

That should be section 5 I believe. Same in a few other places.

[Ballot comment]
On the typo side there seems to have been a generic miss in references to other sections inside the doc (basically it seems it always references the section with an offset of 2). For example section 6:

1. Multi-Prefix Extension generation.  Generate the Multi-Prefix
      Extension with the format defined in section 3.

That should be section 5 I believe. Same in a few other places.

[Ballot discuss]
I am holding a DISCUSS until the following comments from the DNS-DIR review by Peter Koch and the OPS-DIR review by Niclas Comstedt are answered:

1. This draft defines Hash Based Addresses (HBA) for use with shim6.  HBAs are 128bit entities and are treated like IPv6 addresses, which would make them eligible for publicatioon in DNS AAAA RRs.

> 9.  DNS considerations
>
>    HBA sets can be generated using any prefix set.  Actually, the only
>    particularity of the HBA is that they contain information about the
>    prefix set in the interface identifier part of the address in the
>    form of a hash, but no assumption about the properties of prefixes
>    used for the HBA generation is made.  This basically means that
>    depending on the prefixes used for the HBA set generation, it may or
>    may not be recommended to publish the resulting (HBA) addresses in
>    the DNS.  For instance, when ULA prefixes [18] are included in the
>    HBA generation process specific DNS considerations related to the
>    local nature of the ULA should be taken into account and proper
>    reccomendations related to publishing such prefixes in the DNS should
>    followed.

Having a separate "DNS considerations" section is a good idea. The recommendations provided could be a bit more elaborated.  It remains unclear to me whether the HBAs would be published in parallel to the basic locator v6 addresses or as a replacement and how the consuming application would distinguish between both types.

2.

>    In addition, it should be noted that the actual HBA values are a
>    result of the HBA generation procedure meaning that they cannot be
>    arbitrarily chosen.  This has an implication with respect to DNS
>    management, because the party that generates the HBA address set
>    needs to convey the address information to the DNS manager, so that
>    the addresses are published and not the other way round.  The
>    situation is similar to regular CGA addresses and even to the case
>    where stateless address autoconfiguration is used.

It might be worth mentioning DNS Synamic Update explicitly here as well as other means, e.g., a proprietary provisioning system.
Would HBAs be mapped to the hostname via DNS Reverse Mapping?

3. The document addresses a known problem (and references published details on that background). It considers existing/other proposed solutions to the problems but to me makes a compelling argument for why this is an attractive alternative. It also brings up what I believe is the most operational complex part of this solution which is it only supports a predetermined prefix set. You can't dynamically add new prefixes. The draft considers that acceptable considering you would basically need to add a new upstream to hit this issue. Which I agree is rare to be on a similar time scale as any communications using this but it (and CGA for that matter as well) still seems to make it very painful (more then usual) to renumber or even add upstreams. This operational issue needs to be addressed.

4. The other operational point will be that the HBA generation process will dictate what goes into DNS, can't do it the other way around. Which seems to imply that each time you add a prefix to the HBA set you'll need to redo all previous DNS entries for a hosts interfaces unless I'm missing something. So another issue with the main renumber piece.

[Ballot discuss]
The entire discussion is about how the end points determine the valid sets. There is no discussion about how a firewall might react to a dos where the attacker was sending bogus initial Protocol Structures to create false state.

[Ballot discuss]
I am holding a DISCUSS until the following comments from the DNS-DIR review by Peter Koch are answered.

This draft defines Hash Based Addresses (HBA) for use with shim6.  HBAs are 128bit entities and are treated like IPv6 addresses, which would make them eligible for publicatioon in DNS AAAA RRs.

> 9.  DNS considerations
>
>    HBA sets can be generated using any prefix set.  Actually, the only
>    particularity of the HBA is that they contain information about the
>    prefix set in the interface identifier part of the address in the
>    form of a hash, but no assumption about the properties of prefixes
>    used for the HBA generation is made.  This basically means that
>    depending on the prefixes used for the HBA set generation, it may or
>    may not be recommended to publish the resulting (HBA) addresses in
>    the DNS.  For instance, when ULA prefixes [18] are included in the
>    HBA generation process specific DNS considerations related to the
>    local nature of the ULA should be taken into account and proper
>    reccomendations related to publishing such prefixes in the DNS should
>    followed.

Having a separate "DNS considerations" section is a good idea. The recommendations provided could be a bit more elaborated.  It remains unclear to me whether the HBAs would be published in parallel to the basic locator v6 addresses or as a replacement and how the consuming application would distinguish between both types.

>    In addition, it should be noted that the actual HBA values are a
>    result of the HBA generation procedure meaning that they cannot be
>    arbitrarily chosen.  This has an implication with respect to DNS
>    management, because the party that generates the HBA address set
>    needs to convey the address information to the DNS manager, so that
>    the addresses are published and not the other way round.  The
>    situation is similar to regular CGA addresses and even to the case
>    where stateless address autoconfiguration is used.

It might be worth mentioning DNS Synamic Update explicitly here as well as other means, e.g., a proprietary provisioning system.
Would HBAs be mapped to the hostname via DNS Reverse Mapping?

[Ballot discuss]
Section 11.3 suggests that security can be enhanced by using the same public key for IPsec and
CGA.  There are a number of problems with this guidance:

(1) Key lengths for these protocols are unlikely to be consistent.  CGA permits a minimum RSA
key length of 384 bits.  This is far too small for any application of IPsec!

(2) There are cryptographic hygiene issues that are likely to be encountered.  Specifically, the
RSA keys will be used to generate and verify signatures for CGA, but depending upon the IPsec
mode, the keys could be used for key transport.  In general, we like to use cryptographic keys
for a single purpose to avoid some of the more esoteric crypto attacks.

(3) It seems that the bindings for CGA and IPsec are disjoint.  That is, since they provide
assurance for two entirely differnet names, with a relatively weak mapping, the value isn't
clear to me.  A lot more detail is needed for this to be useful.

I would suggest removing section 11.3 in its entirety.

Hannes Tschofenig identified an issue on flooding attacks that should also be addressed.
I have reproduced his comment here:

A small note on the protection against flooding attacks. The draft
says:

  HBAs do not provide complete protection against flooding attacks,
  However, HBAs make very difficult to launch a flooding attack towards
  a specific address.  It is possible though, to launch a flooding
  attack against a prefix.

The claimed protection against flooding attacks can only be accomplished
if SHIM6 with HBA is deployed everywhere. Otherwise, the adversary could
easily claim that it neither supports SHIM6 nor HBA and I doubt that
all these communication are rejected. Furthermore, it seems
that most serious DoS attacks today are accomplished with botnets and the
suggested mechanism does not provide any protection against botnets.

I guess a short note would do it to describe the assumptions and value
of the protection.

[Ballot discuss]
Section 11.3 suggests that security can be enhanced by using the same public key for IPsec and CGA.  There are a number of problems with this guidance:

(1) Key lengths for these protocols are unlikely to be consistent.  CGA permits a minimum RSA
key length of 384 bits.  This is far too small for any application of IPsec!

(2) There are cryptographic hygiene issues that are likely to be encountered.  Specifically, the
RSA keys will be used to generate and verify signatures for CGA, but depending upon the IPsec
mode, the keys could be used for key transport.  In general, we like to use cryptographic keys
for a single purpose to avoid some of the more esoteric crypto attacks.

(3) It seems that the bindings for CGA and IPsec are disjoint.  That is, since they provide
assurance for two entirely differnet names, with a relatively weak mapping, the value isn't
clear to me.  A lot more detail is needed for this to be useful.

I would suggest removing section 11.3 in its entirety.

Hannes Tschofenig identified an issue on flooding attacks that should also be addressed.
I have reproduced his comment here:

A small note on the protection against flooding attacks. The draft
says:

  HBAs do not provide complete protection against flooding attacks,
  However, HBAs make very difficult to launch a flooding attack towards
  a specific address.  It is possible though, to launch a flooding
  attack against a prefix.

The claimed protection against flooding attacks can only be accomplished
if SHIM6 with HBA is deployed everywhere. Otherwise, the adversary could
easily claim that it neither supports SHIM6 nor HBA and I doubt that
all these communication are rejected. Furthermore, it seems
that most serious DoS attacks today are accomplished with botnets and the
suggested mechanism does not provide any protection against botnets.

I guess a short note would do it to describe the assumptions and value
of the protection.

[Ballot discuss]
Section 11.3 suggests that security can be enhanced by using the same public key for IPsec and CGA.  There are a number of problems with this guidance:

(1) Key lengths for these protocols are unlikely to be consistent.  CGA permits a minimum RSA
key length of 384 bits.  This is far too small for any application of IPsec!

(2) There are cryptographic hygiene issues that are likely to be encountered.  Specifically, the
RSA keys will be used to generate and verify signatures for CGA, but depending upon the IPsec mode, the keys could be used for key transport.  In general, we like to use cryptographic keys
for a single purpose to avoid some of the more esoteric crypto attacks.

(3) It seems that the bindings for CGA and IPsec are disjoint.  That is, since they provide
assurance for two entirely differnet names, with a relatively weak mapping, the value isn't
clear to me.  A lot more detail is needed for this to be useful.

I would suggest removing section 11.3 in its entirety.

Hannes Tschofenig identified an issue on flooding attacks that should also be addressed.
I have reproduced his comment here:

A small note on the protection against flooding attacks. The draft
says:

  HBAs do not provide complete protection against flooding attacks,
  However, HBAs make very difficult to launch a flooding attack towards
  a specific address.  It is possible though, to launch a flooding
  attack against a prefix.

The claimed protection against flooding attacks can only be accomplished
if SHIM6 with HBA is deployed everywhere. Otherwise, the adversary could
easily claim that it neither supports SHIM6 nor HBA and I doubt that
all these communication are rejected. Furthermore, it seems
that most serious DoS attacks today are accomplished with botnets and the
suggested mechanism does not provide any protection against botnets.

I guess a short note would do it to describe the assumptions and value
of the protection.

[Ballot comment]
Please review Hannes Tschofenig's secdir review.  While I have added the flooding attack issue
to my discuss some of his editorial comments seem to offer improvements as well.

[Ballot discuss]
Section 11.3 suggests that security can be enhanced by using the same public key for IPsec and CGA.  There are a number of problems with this guidance:

(1) Key lengths for these protocols are unlikely to be consistent.  CGA permits a minimum RSA
key length of 384 bits.  This is far too small for any application of IPsec!

(2) There are cryptographic hygiene issues that are likely to be encountered.  Specifically, the
RSA keys will be used to generate and verify signatures for CGA, but depending upon the IPsec mode, the keys could be used for key transport.  In general, we like to use cryptographic keys
for a single purpose to avoid some of the more esoteric crypto attacks.

(3) It seems that the bindings for CGA and IPsec are disjoint.  That is, since they provide
assurance for two entirely differnet names, with a relatively weak mapping, the value isn't
clear to me.  A lot more detail is needed for this to be useful.

I would suggest removing section 11.3 in its entirety.

Hannes Tschoefenig identified an issue on flooding attacks that should also be addressed.
I have reproduced his comment here:

A small note on the protection against flooding attacks. The draft
says:

  HBAs do not provide complete protection against flooding attacks,
  However, HBAs make very difficult to launch a flooding attack towards
  a specific address.  It is possible though, to launch a flooding
  attack against a prefix.

The claimed protection against flooding attacks can only be accomplished
if SHIM6 with HBA is deployed everywhere. Otherwise, the adversary could
easily claim that it neither supports SHIM6 nor HBA and I doubt that
all these communication are rejected. Furthermore, it seems
that most serious DoS attacks today are accomplished with botnets and the
suggested mechanism does not provide any protection against botnets.

I guess a short note would do it to describe the assumptions and value
of the protection.

[Ballot discuss]
This is a placeholder DISCUSS until we're clear that the issues from Bernard Abobas tsv-dir review have been addressed: http://www1.ietf.org/mail-archive/web/ietf/current/msg49109.html

(I may add to this DISCUSS based on my own IESG review.)

[Ballot comment]
I think this is an excellent spec; I like the way this has been
integrated with CGAs.
Excellent work.

I'm concerned that the description of attack complexity at the
beginning of section 8 is kind of weak. One notably concerning problem
is that I don't think you can add the extra rounds required by the sec
parameter as if they were extra bits of output like that.  Doing so
assumes that there are no shortcuts to the attack being mounted.
That's true for some forms of brute force attack but is definitely not
generally true.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignment in the "CGA Message Type Name Space" registry located at
http://www.iana.org/assignments/cga-message-types
sub-registry "CGA Extension Type Values"

Extension Type    Description              Reference
----------------- ------------------------- ---------
TDB (0x0012)      Multi-prefix              [RFC-shim6-hba-04]


We understand the above to be the only IANA Action for this
document.

I have made my AD review of this document. Please
find comments below. There are a few substantial
issues, but I think they can be corrected fairly
easily. I noted also a number of editorial
issues. I will expect a new revision before we
move forward with this.

This is part 1 of my Shim6-related AD reviews.
The protocol draft is in my queue to be read next;
this will probably take a week or two. Mark will
review the failure detection draft, and I have
also asked him to handle any IPR related discussions,
should they come up during IETF Last Call. We will
wait with the Last Call until all three drafts
can proceed to it.

Here are the comments:

Substantial:

>    Ext Type:  16-bit type identifier of the Multi-Prefix Extension (TBD
>      IANA) (Meanwhile, the 0x12 value is recommended for trails)

A better recommendation would probably be "... the
0xFFFF value, reserved for experimental usage in [RFC 4581],
is recommended for trials before the official IANA
allocation has been granted."

Alternatively, do you want to recommend value 0x12 for the IANA,
*if* implementations have already started to use it?

>    P flag:  Set if a public key is included in the Public Key field of
>      the CGA Parameter Data Structure.  Reset if a additional Modifier
>      bits are included in the CGA Parameter Data Structure.

This is unclear. I think you mean that instead of the public key,
some additional random bits can also appear. But the above two
conditions (if ... if ...) make it hard for the reader to know
whether the two conditions are actually always the reverse of
each other. I think they are. But I would rewrite the above as:

P flag:  Set if a public key is included in the Public Key field of
      the CGA Parameter Data Structure, reset otherwise.


> Second, in the
> case that the address being generated is an HBA-only address, a
> random nonce (encoded in DER as an ASN.1 structure of the type
> SubjectPublicKeyInfo) will have to be used as input instead of a
> valid public key.

Which value would AlgorithmIdentifier take in the ASN.1 structure?
Is the nonce a legal value for that identifier?

>    3. Concatenate from left to right the Modifier, 9 zero octets, the
>      encoded public key or the encoded Extended Modifier (if no public
>      key was provided) and the Multi-Prefix Extension.  Execute the
>      SHA-1 algorithm on the concatenation.  Take the 112 leftmost bits
>      of the SHA-1 hash value.  The result is Hash2.
>
>    4. Compare the 16*Sec leftmost bits of Hash2 with zero.  If they are
>      all zero (or if Sec=0), continue with step (5).  Otherwise,
>      increment the modifier by one and go back to step (3).

RFC 4982 should be referenced here, as it updates the above procedure,
and the words about SHA-1 should be changed accordingly. I.e., SHA-1
is used only for some small Sec values, and other algorithms, to be
defined in the future, could be used for others.

May apply elsewhere in the document, too.

>    The protection against brute force attacks can be improved increasing
>    the Sec parameter.  A non zero Sec parameter implies that steps 3-4
>    of the generation process will be repeated O(2^(16*Sec)) times
>    (expected number of times).  If we assimilate the cost of repeating
>    the steps 3-4 to the cost of generating the HBA address, we can
>    estimate the number of times that the generation is to be repeated in
>    O(2^(59+16*Sec)).

As above.

>    HBA sets can be generated using any prefix set.  Actually, the only
>    particularity of the HBA is that they contain information about the
>    prefix set in the interface identifier part of the address in the
>    form of a hash, but no assumption about the properties of prefixes
>    used for the HBA generation is made.  This basically means that
>    depending on the prefixes used for the HBA set generation, it may or
>    may not be recommended to publish the resulting (HBA) addresses in
>    the DNS.

I am not sure how the third sentence follows from the second.

But more importantly, this seems to simplify the issues
related to DNS implications. Basically, you must be able
to tell the DNS network manager what your IP addresses
are; its not possible for the manager to configure your
DNS entries and addresses.

>    In the case that both IPSec and CGA/HBA address are used
>    simultaneously, it is possible that two public keys are available in
>    a node, one for IPSec and another one for the CGA/HBA operation.  In
>    this case, an improved security can be achieved by verifying that the
>    keys are related somehow, (in particular if the same key is used for
>    both purposes).

Yes, but please state that such verification is outside the
scope of this spec.

Editorial:

>    in the security cosniderations section.

Typo.

>    is used is to inlcude a hash of the permitted prefixes in the low

Typo.


>    It particular, it would possible for an attacker to redirect

Typo.

>      IANA) (Meanwhile, the 0x12 value is recommended for trails)

Trials.

> Reset if a additional Modifier
>      bits are included in the CGA Parameter Data Structure
maybe: "an additional"? or just "additional"?

> 7.1. Verification that a particular HBA address corresponds to a given
>
>      CGA  Parameter Data Strcuture

Typo.

> 7.2. Verification that a particular HBA address belongs tto the HBA set
>
>      associated to a given CGA  Parameter Data Strcuture

Typo.

> However, this not means that this
>    HBA does not belong to the HBA set.
Grammar.

>    o  An CGA Parameter Data Structure

A CGA

> In order to perform this
>    attack the attacker need to generate

Needs?

> In
>    order to do this, the attacker need to find the appropriate Modifier
>    value.
As above.

[Note]: 'Please also read draft-ietf-shim6-applicability
Mark Townsley to handle any IPR questions in AD review/IETF LC/IESG, if any
Document Shepherd is Geoff Huston <gih@apnic.net>
' added by Jari Arkko

[Note]: 'Mark Townsley to handle any IPR questions in AD review/IETF LC/IESG, if any
Document Shepherd is Geoff Huston <gih@apnic.net>
' added by Jari Arkko

(1.a)  Who is the Document Shepherd for this document?
 
          Geoff Huston
         
      Has the Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this version is
      ready for forwarding to the IESG for publication?
     
          Yes

(1.b) Has the document had adequate review both from key members of
      the interested community and others? 
     
        Yes, the document has been explicitly called to the attention of
the Working Group on a number of occasions, and review comments
have been incorporated into the document.
       
        The document has been reviewed by Eric Rescorla for the Security
Are Directorate in November 2005, and the review comments have
been incorporated into the document.
       
      Does the Document Shepherd have any concerns about the depth or
      breadth of the reviews that have been performed?
     
        The Document Shepherd is comfortable with the level of review of
this document.

(1.c) Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective, e.g.,
      security, operational complexity, someone familiar with AAA,
      internationalization or XML?
     

        The document has been revieweed extensively over the past 15
months and the Document Shepherd is comfortable with the
competence and breadth of review of this document.
       
(1.d) Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of?  For example, perhaps he or
      she is uncomfortable with certain parts of the document, or has
      concerns whether there really is a need for it.  In any event, if
      the interested community has discussed those issues and has
      indicated that it still wishes to advance the document, detail
      those concerns here.
     
        The document references Cryptographic Generated Addresses and the
Working Group was informed of IPR statements by Microsoft and
Ericsson that may relate to HBAs. The Working Group has reached a
consensus view that it is comfortable to proceed with recommending
the publication of this document as a Proposed Standard.

(1.e) How solid is the consensus of the interested community behind
      this document?  Does it represent the strong concurrence of a few
      individuals, with others being silent, or does the interested
      community as a whole understand and agree with it?

        The document has been reviewed from a range of perspectives and
has generated review comment from these perspectives. The
consensus behind this document appears to be well-founded.
       
(1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director.  (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)
     
        The document has involved an extensive consideration of IPR issues
on SHIM6 mailing list and at the WG meetings. At one stage an
individual raised the option of appealling any IESG decision to
publish this document as a proposed standard due to potential IPR
encumberance. The WG were aware of this and after extensive
consideration of the nature of the IPR statements there was strong
consensus to proceed with a request to publish these documents.
       

(1.g) Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
      enough; this check needs to be thorough.  Has the document met all
      formal review criteria it needs to, such as the MIB Doctor, media
      type and URI type reviews?
     
        Yes
       
        Reference 12 has since been published as RFC4982. The update to
this document can be undertaken in the form of a note to the RFC
Editor.

There are a number of document typos. The list is:

page 4: s"future/ premeditated"future / premeditated"
page 5: s"Cryptographic Generated Addresses"Cryptographic Generated Addresses (CGA)"
page 6: s"dirven"driven"
page 6: s". this". This"
page 6: s"present a"presents a"
page 6: s"appraoch"approach"
page 6: s"appraoches"approaches"
page 9: s"trails"trials"
page 11: s"Strcuture"Structure"
page 11: s"Strcuture"Structure"
page 11: s"this not means that"this does not mean that"
page 13: s"[Note:"(Note:"
page 13: s"trivially successful becuase"trivial becuase of"
page 13: s"step 1]"step 1)"
page 14: s"him to create"it to create"
page 15: s"global IP address"global IP address."
page 15: s"this means that Host2"This means that Host2"
page 16: s"ad identifier"as an identifier"
        page 20: s"need to generate"needs to generate"
        page 20: s"that the resulting HBA set"where the resulting HBA set"
        page 20: s"[6]. addresses"[6] addresses/
        page 21: s"attacks to currently"attacks on currently"


(1.h) Has the document split its references into normative and
      informative? 
     
        Yes
       
      Are there normative references to documents that are
      not ready for advancement or are otherwise in an unclear state?
     
        No
       
      If such normative references exist, what is the strategy for their
      completion?
     
        Reference [8] is being submitted to the IESG for publication with
this document.
       
      Are there normative references that are downward
      references, as described in [RFC3967]?  If so, list these downward
      references to support the Area Director in the Last Call procedure
      for them [RFC3967].
     
        No
         
(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body of
      the document? 
     
        Yes
       
      If the document specifies protocol extensions, are reservations
      requested in appropriate IANA registries?
     
        Yes
       
      Are the IANA registries clearly identified?
     
        Yes
       
      If the document creates a new registry, does it define the proposed
      initial contents of the registry and an allocation procedure for
      future registrations?
     
        N/A
       
      Does it suggested a reasonable name for the new registry?  See
      [I-D.narten-iana-considerations-rfc2434bis]. 
     
        N/A
       
      If the document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG can
      appoint the needed Expert during the IESG Evaluation?
     
        N/A
       
(1.j) Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML code,
      BNF rules, MIB definitions, etc., validate correctly in an
      automated checker?

        N/A
       

(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Writeup?  Recent examples can be found in the
      "Action" announcements for approved documents.  The approval
      announcement contains the following sections:

      Technical Summary

        Hash Based Addresses are intended to provide a secure binding
between the multiple addresses with different prefixes available
to a host within a multihomed site.  Information about the
multiple prefixes is included within the addresses by generating
the interface identifiers of the addresses of a host as hashes of
the set of available prefixes and a random number, which are then
appended to the the different prefixes.  The result is a set of
addresses that are inherently bound together such that given one
valid address out of the group, the prefix set and the random
number, it is possible to determine whether another address is
part of the group by computing the hash and checking against the
interface identifier value.


      Working Group Summary

        The document has extensively reviewed by the Working Group and by
the Security Area Directorate. The Working Group consensus was to
recommend publication of this document as a Proposed Standard.
       
      Document Quality

        There are known implementations of this specification, and there
have been no implemtation experiences that have implied any
further revision to this specification is required.

The document set (-hba, -protocol, -failure) is being WGLCed again, due to (1) Jim's IPR issue, (2) Jim's other issues, (3) revision of -failure.

Jari has recused himself (announced during IETF-66) from dealing with this document as an AD until the IPR issue is resolved, as he works for the company that holds the IPR (Ericsson).