Subject: Re: shim6 control packets coming from unkown locators
From: marcelo bagnulo braun <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Cc: Jari Arkko <[email-masked]>, shim6 <[email-masked]>
Date: Fri, 28 Sep 2007 08:48:02 +0200

Hi Brian,

El 27/09/2007, a las 21:51, Brian E Carpenter escribió:

> Marcelo,
>
> On 2007-09-28 02:45, marcelo bagnulo braun wrote:
>
> <big snip>
> ...
>> For the R1bis message, it would result in a reduction of security,  
>> since anyone knowing the context tag value could tear down a  
>> context even if he is not located along the path. this could be  
>> enough, though
>> So, the question is general for all the spec, should we support  
>> control messages from unknown locators?
>
> This makes me very nervous that we'd be opening a fairly big security
> hole that would be quite painful to close.
>

agree that security issues should be addressed carefully, but i think  
this is possible, at least for UPDATE packets. Probe packets may  
require a bit more thought, and will require an UPDATE before  
actually sending packets to the locators, but i think it should work.

Regards, marcelo

>    Brian

Delivery-date: Thu, 27 Sep 2007 20:51:36 +0000
Date: Fri, 28 Sep 2007 07:51:42 +1200
From: Brian E Carpenter <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Jari Arkko <[email-masked]>, shim6 <[email-masked]>
Subject: Re: shim6 control packets coming from unkown locators

Marcelo,

On 2007-09-28 02:45, marcelo bagnulo braun wrote:

<big snip>
...
> For the R1bis message, it would result in a reduction of security, since 
> anyone knowing the context tag value could tear down a context even if 
> he is not located along the path. this could be enough, though
> 
> So, the question is general for all the spec, should we support control 
> messages from unknown locators?

This makes me very nervous that we'd be opening a fairly big security
hole that would be quite painful to close.

    Brian

Delivery-date: Thu, 27 Sep 2007 14:45:35 +0000
To: Jari Arkko <[email-masked]>, shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: shim6 control packets coming from unkown locators
Date: Thu, 27 Sep 2007 16:45:19 +0200

Hi Jari,

In your review of the shim6 protocol spec you mentioned:
>
>>    o  Other control messages (Update, Keepalive, Probe): Deliver  
>> to the
>>       context with CT(local) equal to the Receiver Context Tag  
>> included
>>       in the packet.  Verify that the IPv6 source address field is  
>> part
>>       of Ls(peer) and that the IPv6 destination address field is  
>> part of
>>       Ls(local).  If not, send a R1bis message.
>>
>
> Does this prevent properly handling a Probe if the peer
> did not bother to / did not have time to report the
> address as its own? I would expect that hosts might not
> report all addresses, if they have many, and if there's
> a sudden rehoming to a previously unknown prefix,
> the host HAS to send a Probe from this previously
> unknown address. This appears OK from a security
> perspective, at least if we are using CGAs and not
> HBAs.

later on, you mention that:

>
>>    o  An attacker which is present on the path so that it can find  
>> out
>>       the context tags, can generate a R1bis message after it has  
>> moved
>>       off the path.  For this packet to be effective it needs to  
>> have a
>>       source locator which belongs to the context,
>>
>
> Really? What if CGA is used, must the R1bis even then come from a
> previously known address?

In the shim6 protocol as currently defined, all shim6 control  
messages (after R2) must come from locators contained in the locator  
set known by the peer. this applies once the context has been  
established. For I1,R1,I2 and R2 other constraints apply.
So, basically, Update messages, probe messages, R1bis messages, must  
come from a locator included in the locator set known by the peer.

I guess the motivation for this is that the shim6 protocol design was  
focused on multihoming and not in mobility

So, i guess it would be possible to update the spec in order to  
support receiving those messages from previously unkown locators. In  
the case of UPDATE messages could be easy, because we could require  
that the update message must contain the new locator that is being  
used as source address, signed.
In the case of the probe message, it may be ok to receive messages  
from an unknown locator, but it wouldn't be possible to send packets  
to it until it hasn't been properly verified i.e. an update message  
signed has been received
For the R1bis message, it would result in a reduction of security,  
since anyone knowing the context tag value could tear down a context  
even if he is not located along the path. this could be enough, though

So, the question is general for all the spec, should we support  
control messages from unknown locators?

Regards, marcelo

Delivery-date: Thu, 27 Sep 2007 14:11:56 +0000
Cc: [email-masked], shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: AD review of draft-ietf-shim6-proto -- section 5
Date: Thu, 27 Sep 2007 16:10:50 +0200
To: Jari Arkko <[email-masked]>

Hi Jari,

there was one remaining issue from this message

El 16/09/2007, a las 20:07, Jari Arkko escribió:
>>> Are generation counters unique per context tag?
>>>
>>
>> I don't think this is strictly needed, but i guess in practice they
>> will be in most of the cases, since i doubt there will be more than
>> 2^32 different locator lists.
>> What is needed is to prevent that two locator lists are confused, so
>> generating the locator list generation as described, this is avoided.
>> However, it would be perfectly ok to repeat a number if both ends are
>> certain that there is no confusion (for example the value was used a
>> long time ago and both ends are certain that the value is no  
>> longer in
>> use)
>>
>> so i am not sure what is the best option here... i mean i don't think
>> we need to require using every generation value only once during the
>> lifetime of a context, because it would be hard to enforce  
>> (especially
>> during reboots) One option would be to require uniqueness as long as
>> there are no reboots
>>
>>
>> As it currently described in the document, generation values are
>> increased each time a new locator list is exchanged, so they will not
>> be repeated but there is no problem of repeating when there are
>> reboots, since there is no explicity requirement to avoid repetition,
>> which i think it is the right approach. However, i am not sure how to
>> explain this clearly in terms of uniqueness requirements of the
>> generation values...
>
> Is there any chance of generation counters from two different
> contexts (e.g., forking, re-establishment after reboot) be mixed
> up somehow?

i don't think so because the reboot case is the one i have cosnidered  
above and the forking case is not possible netiher, because the  
update message carries the context tag, which is different for  
different forked instances of a context, so it would actually be  
considered as different contexts (in this case the context confusion  
techniques would prevent mixing two contexts, so they also would  
prevent a case where the context tag and the generation number are  
repeated)

> If not, there's really no problem.
>

ok, so i will leave it as it is

> I don't recall if you said something anywhere about
> how generation counters are searched; my assumption
> is that you only do that check/search within the
> context. I think it would be good to state that.
>

the following text is included in the draft:

10.4.  Receiving Update Request messages

...

    Upon the reception of an Update Request message, the host extracts
    the Context Tag from the message.  It then looks for a context which
    has a CT(local) that matches the context tag.

(so, the packet is only processed within the context associated with  
the context tag)

then in the same section it is stated that:

    If the Update message contains a Locator Preference option, then the
    Generation number in the preference option is compared with the peer
    generation number in the context.  If they do not match, then the
    host generates a Shim6 Error Message with Error Code=3 with the
    Pointer field referring to the first octet in the Generation number
    in the Locator Preference option.  In addition, if the number of
    elements in the Locator Preference option does not match the number
    of locators in Ls(peer), then a Shim6 Error Message with Error  
Code=4
    is sent with the Pointer referring to the first octet of the Length
    field in the Locator Preference option.  In both cases of failures,
    no further processing is performed for the Locator Update message.

would this be enough or do you think additional text is needed?

regards, marcelo

Delivery-date: Wed, 19 Sep 2007 22:15:15 +0000
Cc: [email-masked], shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: AD review of draft-ietf-shim6-proto -- sections 7.18 through 14
Date: Mon, 17 Sep 2007 13:22:13 +0200
To: Jari Arkko <[email-masked]>

continuing....

El 13/09/2007, a las 15:35, Jari Arkko escribió:

>
> Still continuing with the review. Sigh, its
> a long document... I also noticed a few
> things that forced me to go back in the document,
> so don't be surprised about Section numbers
> below 7.18.
>
> Substantial:
>
> (From Section 5.10)
>>  CGA Parameter Data Structure (PDS):  Included when the locator list
>>  is included and the PDS was not included in the I2/
>>  I2bis/R2 messages, so the receiver can verify the
>>  locator list.
> (From Section 7.10)
>>  In
>>  particular, the R2 message includes the Responder's locator list and
>>  the PDS option.
> (From Section 7.16)
>>  If a CGA Parameter Data Structure (PDS) is
>>  included in the message, then the host MUST verify that the actual
>>  PDS contained in the message corresponds to the ULID(peer) as
>>  specified in Section 7.2.
>
> I am getting confused about when the PDS appears in the
> message when not. 7.10 seems to say its always there;
> 7.16 allows it to not be there; 5.10 explains some
> of the thinking. I think we need to be consistent with
> these recommendations, perhaps fixing Section 7.10
> language.

exactly

the point is that the PDS must be included the first time additional  
locators are exchanged. This may be in the I2/I2bis/R2 or Update  
message.
Probably the normal situation will be that they are exchanged in the  
I2/I2bis/R2, but we don't need to rule out that this is delayed till  
the UPDATE message

I have rephrased sections about I2, R2, I2bis in order to clarify  
this. The result is that the locator list and the PDS may be included  
in any of these messages

>
>> CGA Parameter Data Structure:  Included when the locator list is
>> included so the receiver can verify the locator list.
>
> There should be some discussion in the introductory
> parts of the document about the (non-)requirements to
> use HBA/CGA addresses on both sides. My understanding
> is that its OK for my multihomed host to have such
> addresses and that Shim6 still works with a host on
> the other side that only has one address. Right?
>

I have addressed this point below...

>>    A shim control message has the checksum field verified.  The Shim
>>    header length field is also verified against the length of the  
>> IPv6
>>    packet to make sure that the shim message doesn't claim to end  
>> past
>>    the end of the IPv6 packet.  Finally, it checks that the  
>> neither the
>>    IPv6 destination field nor the IPv6 source field is a multicast
>>    address.  If any of those checks fail, the packet is silently
>>    dropped.
>
> Are multicast addresses only ones that need to be prohibited?
> What about unspecified, link local unicast?

i guess we should not allow unspecified. I am not sure we should rule  
out link local... perhaps someone would want to use shim6 between two  
local machines with multiple interfaces....

are you ok ruling out unspcified and not mentioning link local?

>
> Section 10:
>
>>    If a CGA Parameter Data Structure (PDS) is included in the  
>> message,
>>    then the host MUST verify if the actual PDS contained in the  
>> packet
>>    corresponds to the ULID(peer).  If this verification fails, the
>>    message is silently discarded.
>
> This is probably explained in more detail elsewhere, but the
> above statement "correspond to the ULID(peer)" seems incorrect.
> Lets assume we have locators L1, L2, L3, L4. Lets further assume
> that ULID=L4. Now, we indeed need to verify that, e.g., the
> HBA equations prove L1, L2, L3, and L4 are related. I guess
> this can be stated as "PDS corresponds to the ULID(peer)".
> But how does this work for CGAs? Lets assume for the sake
> of argument that the CGA address = L1 and ULID is still L4.

but this is not enough to provide the required protection. I mean,  
when using CGAs, the CGA must be the ULID, so identifier ownership  
can be proven. Actually, when using CGAs, it is not needed that an  
address that is exclusively used as a locator is a CGAs, but the ULID  
must be a CGA, hence the text

> This seems possible, but it no longer holds that "PDS
> corresponds to ULID(peer)". Instead, you need to show
> one of the two: each address in the list is either hash(key)
> or the key has been used to sign the entire Update message,
> showing willingness of the key owner to use these other
> addresses.
>

i think that in this example, it is not enough to prove that the  
alternative locators are bounded to the ulid by the ulid owner, since  
it is not signed by the key associated to the uild.

> Reformulation of this text is probably needed. It appears
> in multiple places in the document, so make sure you fix
> all places.
>

i think that what is needed is to mention that the ulid must be a cga  
if cgas are used, makes sense?

i have added the following text in the assumptions section  
(addressing this point and a previous one)

<t> The security of the Shim6 protocol relies on the usage of Hash  
Based Addresses (HBA)
<xref target='I-D.ietf-shim6-hba'/> and/or Cryptographically  
Generated Addresses (CGA)
<xref target='RFC3972'/>. In the case that HBAs are used, all the  
addresses assigned
to the host that are included in the Shim6 protocol (either as a  
locator or as a ULID) must be part of the same HBA set.
In the case that CGAs are used, the address used as ULID must be a  
CGA but the other addresses that are used as locators do not need to  
be neither CGAs nor HBAs.
It should be noted that it is perfectly acceptable to run the Shim6  
protocol
between a host that has multiple locators and another host that has a  
single IP address.
In this case, the address of the host with a single address does not  
need to be an HBA nor a CGA.
</t>

>> The host uses the Probe message in [9] to verify
>> that the new locator is reachable before changing Lp(peer).
>
> The host uses the specific message, or runs the
> entire protocol?

the whole exploration protocol

I have rephrased as follows

The host uses the reachability exploration procedure described in [9]  
to verify
that the new locator is reachable before changing Lp(peer).

> If the former, please specify in
> more detail the contents of the message.
> 		
>>    o  Other control messages (Update, Keepalive, Probe): Deliver  
>> to the
>>       context with CT(local) equal to the Receiver Context Tag  
>> included
>>       in the packet.  Verify that the IPv6 source address field is  
>> part
>>       of Ls(peer) and that the IPv6 destination address field is  
>> part of
>>       Ls(local).  If not, send a R1bis message.
>
> Does this prevent properly handling a Probe if the peer
> did not bother to / did not have time to report the
> address as its own? I would expect that hosts might not
> report all addresses, if they have many, and if there's
> a sudden rehoming to a previously unknown prefix,
> the host HAS to send a Probe from this previously
> unknown address. This appears OK from a security
> perspective, at least if we are using CGAs and not
> HBAs.
>

I will address this comment later...

regards, marcelo

> Jari
>
>

Delivery-date: Wed, 19 Sep 2007 22:14:45 +0000
Cc: [email-masked], shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: AD review of draft-ietf-shim6-proto -- sections 15 through the  end
Date: Mon, 17 Sep 2007 13:22:05 +0200
To: Jari Arkko <[email-masked]>

El 13/09/2007, a las 23:38, Jari Arkko escribió:

>
> Continuing with the review. This goes right to the end,
> and I have set the state of the document to Revised ID
> Needed. I will still send some summary conclusions
> after thinking about the results of the review. But
> overall I'm relatively happy, almost everything that
> I found was just minor issues. Its a tough document
> to read given its size, but very well written and
> there was a very small number of obvious problems.
>
> Substantial:
>
>>    The Shim6 sub-layer is implemented below the IPSec layer within  
>> the
>>    IP layer.  This deserves some additional considerations for a  
>> couple
>>    of specific cases: First, it should be noted that the Shim6  
>> approach
>>    does not preclude using IPSEC tunnels on Shim6 packets within the
>>    network transit path.  Second, in case that IPSec is  
>> implemented as
>>    Bump-In-The-Wire (BITW) [7], either the shim MUST be disabled,  
>> or the
>>    shim MUST also be implemented as Bump-In-The-Wire, in order to
>>    satisfy the requirement that IPsec is layered above the shim.
>
> Presumably the BITW implementation could also itself
> filter out Shim6 control packets, in which case the
> shim is never turned on.
>

agree, do you want me to add that sentence at the end of this paragraph?

>>    o  An attacker which is present on the path so that it can find  
>> out
>>       the context tags, can generate a R1bis message after it has  
>> moved
>>       off the path.  For this packet to be effective it needs to  
>> have a
>>       source locator which belongs to the context,
>
> Really? What if CGA is used, must the R1bis even then come from a
> previously known address?
>

will address this point later.

> Editorial:

done

regards, marcelo

>
>> In this case, it reccomended that the
> ...
>>    Shim6 follows the reccomendation defined in [28] and it informs  
>> the
>
> Typos.
>
>> in order to allow the congestion
>> control mechanisms of the upper layers can react accordingly.
>
> s/can/to/
>
>>    The Shim6 sub-layer is implemented below the IPSec layer within  
>> the
>>    IP layer.  This deserves some additional considerations for a  
>> couple
>>    of specific cases: First, it should be noted that the Shim6  
>> approach
>>    does not preclude using IPSEC tunnels on Shim6 packets within the
>
> Different capitalizations of IPsec, none correct.
>
> Jari
>

Delivery-date: Sun, 16 Sep 2007 18:07:42 +0000
Date: Sun, 16 Sep 2007 21:07:11 +0300
From: Jari Arkko <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC:  [email-masked], shim6 <[email-masked]>,  "W. Mark Townsley" <[email-masked]>
Subject: Re: AD review of draft-ietf-shim6-proto -- section 5

Marcelo,

> I don't think so, because basically, when one end reboots, the
> established context is lost and needs to be recovered. The recovery
> procedure basically re runs the context establishment procedure
> (without requiring the I1 message) but in any case, a new locator list
> is exchanged and the locator list generation value is updated
> accordingly in the context recovery procedure.
>
> So, i don't think the value must persists during reboots, so i guess
> it would be ok to leave the text as it is or would you prefer to
> include a comment explicitly stating the lack of need for persistence
> during reboots?

Its fine without new text. Thanks for the explanation.

>> Is there a window that one should be following?
>
> I don't think so, because this option is exchanged in I2, R2 or UPDATE
> message, and all of them are acked, so if no ack is received the
> sender should stick to the old value. Same question than above, should
> we include something about this in the document?

Probably not needed.

>> Are generation counters unique per context tag?
>>
>
> I don't think this is strictly needed, but i guess in practice they
> will be in most of the cases, since i doubt there will be more than
> 2^32 different locator lists.
> What is needed is to prevent that two locator lists are confused, so
> generating the locator list generation as described, this is avoided.
> However, it would be perfectly ok to repeat a number if both ends are
> certain that there is no confusion (for example the value was used a
> long time ago and both ends are certain that the value is no longer in
> use)
>
> so i am not sure what is the best option here... i mean i don't think
> we need to require using every generation value only once during the
> lifetime of a context, because it would be hard to enforce (especially
> during reboots) One option would be to require uniqueness as long as
> there are no reboots
>
>
> As it currently described in the document, generation values are
> increased each time a new locator list is exchanged, so they will not
> be repeated but there is no problem of repeating when there are
> reboots, since there is no explicity requirement to avoid repetition,
> which i think it is the right approach. However, i am not sure how to
> explain this clearly in terms of uniqueness requirements of the
> generation values...

Is there any chance of generation counters from two different
contexts (e.g., forking, re-establishment after reboot) be mixed
up somehow? If not, there's really no problem.

I don't recall if you said something anywhere about
how generation counters are searched; my assumption
is that you only do that check/search within the
context. I think it would be good to state that.

>>>                            +-------+----------+
>>>                            | Value |  Method  |
>>>                            +-------+----------+
>>>                            |   0   | Reserved |
>>>                            |       |          |
>>>                            |   1   |    HBA   |
>>>                            |       |          |
>>>                            |   2   |    CGA   |
>>>                            |       |          |
>>>                            | 3-255 | Reserved |
>>>                            +-------+----------+
>>
>> I'm reading on, but what if it is the kind of
>> a combined HBA and CGA as described in the shim6-hba
>> draft? Presumably you indicate HBA if the locator
>> is in the fixed set and CGA if its in the dynamic,
>> but it would be good to clarify this.
>>
>
> note that for a locator list of n locators there are n locator
> verification method octets, since it is stated that:
>
>   Verification Method:  N octets.  The i'th octet specifies the
>                   verification method for the i'th locator.
>
> So each locator will have its associated verification method. So in
> case that a hybrid CGA/HBA is being used, the locators validated with
> HBA will have their verification method marked to HBA and in the case
> of those locators validated with CGA they will have its verification
> method marked are CGA.
>
> This part it is a bit tricky, do you think it requires further
> clarification?

No, this explanation is fine.

>>>    This option contains the CGA Parameter Data Structure (PDS).  When
>>>    HBA is used to verify the locators, the PDS contains the HBA
>>>    multiprefix extension.  When CGA is used to verify the locators, in
>>>    addition to the PDS option, the host also needs to include the
>>>    signature in the form of a CGA Signature option.
>>
>> The Parameter Data Structure contains more than the
>> multiprefix extension, e.g., the public key, the
>> random bits instead of a public key for HBAs, and
>> any options unrelated to Shim6 that the CGA might
>> have. I would remove the second sentence above or
>> reword it to make sure that you really do include
>> the FULL CGA Parameter Data Structure.
>>
>
> reworded as follows:
>
>    This option contains the CGA Parameter Data Structure (PDS). When
>    HBA is used to verify the locators, the PDS contains the HBA
>    multiprefix extension in addition to the PDS mandatory fields and
>    other extensions unrelated to Shim6 that the PDS might have.
>    When CGA is used to verify the locators, in
>    addition to the PDS option, the host also needs to include the
>    signature in the form of a CGA Signature option.

Looks good, thanks.

Jari

Delivery-date: Sun, 16 Sep 2007 17:34:58 +0000
Cc: [email-masked], shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: AD review of draft-ietf-shim6-proto -- section 5
Date: Sun, 16 Sep 2007 17:07:32 +0200
To: Jari Arkko <[email-masked]>

Hi Jari,

thanks for the review, see inline comments below

El 11/09/2007, a las 22:00, Jari Arkko escribió:

>
> Continuing with the review:
>
> Substantial:
>
>>    The following options are defined for this message:
>>
>>    Responder Validator:  Variable length option.  Typically a hash
>>                   generated by the responder, which the responder  
>> uses
>>                   together with the Responder Nonce value to  
>> verify that
>>                   an I2 message is indeed sent in response to a R1
>>                   message, and that the parameters in the I2  
>> message are
>>                   the same as those in the I1 message.
>
> (Appears in multiple places in the document).
>
> Is the use of this option mandatory?

this option is mandatory for R1 and I2 messages

I have added that to the description of R1 and I2 messages

> What about its copying
> on the other side, if it is present? Please clarify.
>

Yes, the initiator must copy it when receiving the R1 and generating  
the I2 message

i have added that to the document in the section describing the I2  
message

>> Locator List Generation:  32-bit unsigned integer.  Indicates a
>> generation number which is increased by one for each
>> new locator list.  This is used to ensure that the
>> index in the Locator Preferences refer to the right
>> version of the locator list.
>
> Are there requirements on keeping this generation counter
> unique across reboots, or would rolling back not cause
> a problem?

good point

I don't think so, because basically, when one end reboots, the  
established context is lost and needs to be recovered. The recovery  
procedure basically re runs the context establishment procedure  
(without requiring the I1 message) but in any case, a new locator  
list is exchanged and the locator list generation value is updated  
accordingly in the context recovery procedure.

So, i don't think the value must persists during reboots, so i guess  
it would be ok to leave the text as it is or would you prefer to  
include a comment explicitly stating the lack of need for persistence  
during reboots?

> Is there a window that one should be following?

I don't think so, because this option is exchanged in I2, R2 or  
UPDATE message, and all of them are acked, so if no ack is received  
the sender should stick to the old value. Same question than above,  
should we include something about this in the document?

> Are generation counters unique per context tag?
>

I don't think this is strictly needed, but i guess in practice they  
will be in most of the cases, since i doubt there will be more than  
2^32 different locator lists.
What is needed is to prevent that two locator lists are confused, so  
generating the locator list generation as described, this is avoided.  
However, it would be perfectly ok to repeat a number if both ends are  
certain that there is no confusion (for example the value was used a  
long time ago and both ends are certain that the value is no longer  
in use)

so i am not sure what is the best option here... i mean i don't think  
we need to require using every generation value only once during the  
lifetime of a context, because it would be hard to enforce  
(especially during reboots) One option would be to require uniqueness  
as long as there are no reboots

As it currently described in the document, generation values are  
increased each time a new locator list is exchanged, so they will not  
be repeated but there is no problem of repeating when there are  
reboots, since there is no explicity requirement to avoid repetition,  
which i think it is the right approach. However, i am not sure how to  
explain this clearly in terms of uniqueness requirements of the  
generation values...

>>                            +-------+----------+
>>                            | Value |  Method  |
>>                            +-------+----------+
>>                            |   0   | Reserved |
>>                            |       |          |
>>                            |   1   |    HBA   |
>>                            |       |          |
>>                            |   2   |    CGA   |
>>                            |       |          |
>>                            | 3-255 | Reserved |
>>                            +-------+----------+
>
> I'm reading on, but what if it is the kind of
> a combined HBA and CGA as described in the shim6-hba
> draft? Presumably you indicate HBA if the locator
> is in the fixed set and CGA if its in the dynamic,
> but it would be good to clarify this.
>

note that for a locator list of n locators there are n locator  
verification method octets, since it is stated that:

   Verification Method:  N octets.  The i'th octet specifies the
                   verification method for the i'th locator.

So each locator will have its associated verification method. So in  
case that a hybrid CGA/HBA is being used, the locators validated with  
HBA will have their verification method marked to HBA and in the case  
of those locators validated with CGA they will have its verification  
method marked are CGA.

This part it is a bit tricky, do you think it requires further  
clarification?

>>    This option contains the CGA Parameter Data Structure (PDS).  When
>>    HBA is used to verify the locators, the PDS contains the HBA
>>    multiprefix extension.  When CGA is used to verify the  
>> locators, in
>>    addition to the PDS option, the host also needs to include the
>>    signature in the form of a CGA Signature option.
>
> The Parameter Data Structure contains more than the
> multiprefix extension, e.g., the public key, the
> random bits instead of a public key for HBAs, and
> any options unrelated to Shim6 that the CGA might
> have. I would remove the second sentence above or
> reword it to make sure that you really do include
> the FULL CGA Parameter Data Structure.
>

reworded as follows:

    This option contains the CGA Parameter Data Structure (PDS). When
    HBA is used to verify the locators, the PDS contains the HBA
    multiprefix extension in addition to the PDS mandatory fields and
    other extensions unrelated to Shim6 that the PDS might have.
    When CGA is used to verify the locators, in
    addition to the PDS option, the host also needs to include the
    signature in the form of a CGA Signature option.

> Editorial:
>

done

regards, marcelo

>>    included, the packet would become larger than 1280 bytes.Another
>
> s/[.]/. /
>
>>     0                   1                   2                   3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |  Next Header  |  Hdr Ext Len  |0|     Type    |Type-specific|0|
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |            Checksum           |                               |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
>>    |                    Type-specific format                       |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>    Fields:
>>
>>    Next Header:   8-bit selector.  Normally set to NO_NXT_HDR (59).
>>
>>    Hdr Ext Len:   8-bit unsigned integer.  Length of the Shim6  
>> header in
>>                   8-octet units, not including the first 8 octets.
>>
>>    P:             Set to zero.  A single bit to distinguish this from
>>                   the Shim6 payload extension header.
>>
>>    Type:          7-bit unsigned integer.  Identifies the actual  
>> message
>>                   from the table below.  Type codes 0-63 will not
>>                   trigger R1bis messages on a missing context,  
>> while 64-
>>                   127 will trigger R1bis.
>>
>>    0:             A single bit (set to zero) which allows Shim6  
>> and HIP
>>                   to have a common header format yet telling Shim6  
>> and
>>                   HIP messages apart.
>
> Here I got confused about the two 0's. The first one is P in the list,
> the other one is "0". Maybe you need to set one of the zeroes in the
> picture to something else (P or R), or add some text to make this
> clearer.
>
> Jari

Delivery-date: Sun, 16 Sep 2007 17:34:28 +0000
Cc: [email-masked], shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: AD review of draft-ietf-shim6-proto -- sections 6 through 7.17
Date: Sun, 16 Sep 2007 17:40:46 +0200
To: Jari Arkko <[email-masked]>

Hi Jari,

El 12/09/2007, a las 16:59, Jari Arkko escribió:

>
> Continuing with the review:
>
> Substantial:
>
>>    o  For each peer locator, a flag whether it has been verified  
>> using
>>       HBA or CGA, and a bit whether the locator has been probed to
>>       verify that the ULID is present at that location.
>
> Is there a need to remember *when* such probing has last
> happened? If not, why not?
>

My view on this one is:

There are two perspectives for this test: the security perspective  
and the reachability perspective.

This document only deals with the security perspective, while the  
reachability perspective is detailed in the failure detection  
document. For the reachability perspective, this info and other info  
may be needed, but this is not covered by this document, since the  
failure detection document describes this part in detail.

 From the security perspective, this is covered in this document, and  
i don't think the time information is needed. I mean, if the test has  
been successful once, then you have a sufficient protection against  
flooding attacks imho (we do not need to protect against time shifted  
flooding attacks imho)
Please note that section 7.2. locator verification reccommends that  
the reachability verification is performed just before the locator is  
to be used, which seems to me the appropriate time to do this.

So, to proceed i would ask:

do you think we need to include additional information that is used  
for reachability status or is it ok that this is not covered by this  
document and covered by the failure detection document?
do you agree that the proper level of security is achieved without  
keeping track about when the test was performed or do you think this  
info is needed?

>>    o  The preferred peer locator - used as destination; Lp(peer)
>
> First, this sentence was hard to parse. Second, preferred != the
> one we are using as a destination. Please explain or
> modify. Did you mean the current locator that we are using?

yes, the preferred peer locator is the one we are using as destination

> The failure-detection draft uses the term "current address
> pair", so it would be good to align with that.

ok, i have changed it to current peer locator

and i have rephrased it to make it clearer as:

    o  The current peer locator, is the locator used as destination  
address when sending packets; Lp(peer)

similarly to the source one:

    o  The current local locator, is the locator used as source  
address when sending packets; Lp(local)

regards, marcelo

> I'm reading
> on...
>
>>    o  The preferred local locator - used as source; Lp(local)
>
> As above.
>
> Jari
>

Delivery-date: Thu, 13 Sep 2007 21:39:37 +0000
Date: Fri, 14 Sep 2007 00:38:41 +0300
From: Jari Arkko <[email-masked]>
To:  [email-masked]
CC: shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
Subject: AD review of draft-ietf-shim6-proto -- sections 15 through the end

Continuing with the review. This goes right to the end,
and I have set the state of the document to Revised ID
Needed. I will still send some summary conclusions
after thinking about the results of the review. But
overall I'm relatively happy, almost everything that
I found was just minor issues. Its a tough document
to read given its size, but very well written and
there was a very small number of obvious problems.

Substantial:

>    The Shim6 sub-layer is implemented below the IPSec layer within the
>    IP layer.  This deserves some additional considerations for a couple
>    of specific cases: First, it should be noted that the Shim6 approach
>    does not preclude using IPSEC tunnels on Shim6 packets within the
>    network transit path.  Second, in case that IPSec is implemented as
>    Bump-In-The-Wire (BITW) [7], either the shim MUST be disabled, or the
>    shim MUST also be implemented as Bump-In-The-Wire, in order to
>    satisfy the requirement that IPsec is layered above the shim.

Presumably the BITW implementation could also itself
filter out Shim6 control packets, in which case the
shim is never turned on.

>    o  An attacker which is present on the path so that it can find out
>       the context tags, can generate a R1bis message after it has moved
>       off the path.  For this packet to be effective it needs to have a
>       source locator which belongs to the context,

Really? What if CGA is used, must the R1bis even then come from a
previously known address?

Editorial:

> In this case, it reccomended that the
...
>    Shim6 follows the reccomendation defined in [28] and it informs the

Typos.

> in order to allow the congestion
> control mechanisms of the upper layers can react accordingly.

s/can/to/

>    The Shim6 sub-layer is implemented below the IPSec layer within the
>    IP layer.  This deserves some additional considerations for a couple
>    of specific cases: First, it should be noted that the Shim6 approach
>    does not preclude using IPSEC tunnels on Shim6 packets within the

Different capitalizations of IPsec, none correct.

Jari

Delivery-date: Thu, 13 Sep 2007 13:37:03 +0000
Date: Thu, 13 Sep 2007 16:35:30 +0300
From: Jari Arkko <[email-masked]>
To:  [email-masked]
CC: shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
Subject: AD review of draft-ietf-shim6-proto -- sections 7.18 through 14

Still continuing with the review. Sigh, its
a long document... I also noticed a few
things that forced me to go back in the document,
so don't be surprised about Section numbers
below 7.18.

Substantial:

(From Section 5.10)
>  CGA Parameter Data Structure (PDS):  Included when the locator list
>  is included and the PDS was not included in the I2/
>  I2bis/R2 messages, so the receiver can verify the
>  locator list.
(From Section 7.10)
>  In
>  particular, the R2 message includes the Responder's locator list and
>  the PDS option. 
(From Section 7.16)
>  If a CGA Parameter Data Structure (PDS) is
>  included in the message, then the host MUST verify that the actual
>  PDS contained in the message corresponds to the ULID(peer) as
>  specified in Section 7.2. 

I am getting confused about when the PDS appears in the
message when not. 7.10 seems to say its always there;
7.16 allows it to not be there; 5.10 explains some
of the thinking. I think we need to be consistent with
these recommendations, perhaps fixing Section 7.10
language.

Same with Section 7.11 (sending I2) vs. Section
7.13 (receiving I2).

And 7.14 vs. 7.16 (for R2).

> 7.18. Receiving R1bis messages and sending I2bis messages
> (nothing about PDS)
> ...
> 7.20. Receiving I2bis messages and sending R2 messages
>    ...
>    If a CGA Parameter Data Structure (PDS) is included in the message,
>    then the host MUST verify if the actual PDS contained in the message
>    corresponds to the ULID(peer).

Inconsistent here, too.

> 10.1. Sending Update Request messages
> 
> 
>    When a host has a change in the locator set, then it can communicate
>    this to the peer by sending an Update Request.  When a host has a
>    change in the preferences for its locator set, it can also
>    communicate this to the peer.  The Update Request message can include
>    just a Locator List option, to convey the new set of locators (which
>    requires a CGA signature option as well), just a Locator Preferences
>    option, or both a new Locator List and new Locator Preferences.
> 
> ...
> 
> 10.4. Receiving Update Request messages
> 
>    ...
>    If a CGA Parameter Data Structure (PDS) is included in the message,
>    then the host MUST verify if the actual PDS contained in the packet
>    corresponds to the ULID(peer).  If this verification fails, the
>    message is silently discarded.

Again, the text about sending the Update does not talk
about the PDS, while the receiving side does. This
needs to be consistent.

> CGA Parameter Data Structure:  Included when the locator list is
> included so the receiver can verify the locator list.

There should be some discussion in the introductory
parts of the document about the (non-)requirements to
use HBA/CGA addresses on both sides. My understanding
is that its OK for my multihomed host to have such
addresses and that Shim6 still works with a host on
the other side that only has one address. Right?

>    A shim control message has the checksum field verified.  The Shim
>    header length field is also verified against the length of the IPv6
>    packet to make sure that the shim message doesn't claim to end past
>    the end of the IPv6 packet.  Finally, it checks that the neither the
>    IPv6 destination field nor the IPv6 source field is a multicast
>    address.  If any of those checks fail, the packet is silently
>    dropped.

Are multicast addresses only ones that need to be prohibited?
What about unspecified, link local unicast?

Section 10:

>    If a CGA Parameter Data Structure (PDS) is included in the message,
>    then the host MUST verify if the actual PDS contained in the packet
>    corresponds to the ULID(peer).  If this verification fails, the
>    message is silently discarded.

This is probably explained in more detail elsewhere, but the
above statement "correspond to the ULID(peer)" seems incorrect.
Lets assume we have locators L1, L2, L3, L4. Lets further assume
that ULID=L4. Now, we indeed need to verify that, e.g., the
HBA equations prove L1, L2, L3, and L4 are related. I guess
this can be stated as "PDS corresponds to the ULID(peer)".
But how does this work for CGAs? Lets assume for the sake
of argument that the CGA address = L1 and ULID is still L4.
This seems possible, but it no longer holds that "PDS
corresponds to ULID(peer)". Instead, you need to show
one of the two: each address in the list is either hash(key)
or the key has been used to sign the entire Update message,
showing willingness of the key owner to use these other
addresses.

Reformulation of this text is probably needed. It appears
in multiple places in the document, so make sure you fix
all places.

> The host uses the Probe message in [9] to verify
> that the new locator is reachable before changing Lp(peer).

The host uses the specific message, or runs the
entire protocol? If the former, please specify in
more detail the contents of the message.

>    o  Other control messages (Update, Keepalive, Probe): Deliver to the
>       context with CT(local) equal to the Receiver Context Tag included
>       in the packet.  Verify that the IPv6 source address field is part
>       of Ls(peer) and that the IPv6 destination address field is part of
>       Ls(local).  If not, send a R1bis message.

Does this prevent properly handling a Probe if the peer
did not bother to / did not have time to report the
address as its own? I would expect that hosts might not
report all addresses, if they have many, and if there's
a sudden rehoming to a previously unknown prefix,
the host HAS to send a Probe from this previously
unknown address. This appears OK from a security
perspective, at least if we are using CGAs and not
HBAs.

Jari

Delivery-date: Wed, 12 Sep 2007 15:00:50 +0000
Date: Wed, 12 Sep 2007 17:59:51 +0300
From: Jari Arkko <[email-masked]>
To:  [email-masked]
CC: shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
Subject: AD review of draft-ietf-shim6-proto -- sections 6 through 7.17

Continuing with the review:

Substantial:

>    o  For each peer locator, a flag whether it has been verified using
>       HBA or CGA, and a bit whether the locator has been probed to
>       verify that the ULID is present at that location.

Is there a need to remember *when* such probing has last
happened? If not, why not?

>    o  The preferred peer locator - used as destination; Lp(peer)

First, this sentence was hard to parse. Second, preferred != the
one we are using as a destination. Please explain or
modify. Did you mean the current locator that we are using?
The failure-detection draft uses the term "current address
pair", so it would be good to align with that. I'm reading
on...

>    o  The preferred local locator - used as source; Lp(local)

As above.

Jari

Delivery-date: Tue, 11 Sep 2007 20:01:28 +0000
Date: Tue, 11 Sep 2007 23:00:17 +0300
From: Jari Arkko <[email-masked]>
To:  [email-masked]
CC: shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
Subject: AD review of draft-ietf-shim6-proto -- section 5

Continuing with the review:

Substantial:

>    The following options are defined for this message:
> 
>    Responder Validator:  Variable length option.  Typically a hash
>                   generated by the responder, which the responder uses
>                   together with the Responder Nonce value to verify that
>                   an I2 message is indeed sent in response to a R1
>                   message, and that the parameters in the I2 message are
>                   the same as those in the I1 message.

(Appears in multiple places in the document).

Is the use of this option mandatory? What about its copying
on the other side, if it is present? Please clarify.

> Locator List Generation:  32-bit unsigned integer.  Indicates a
> generation number which is increased by one for each
> new locator list.  This is used to ensure that the
> index in the Locator Preferences refer to the right
> version of the locator list.

Are there requirements on keeping this generation counter
unique across reboots, or would rolling back not cause
a problem? Is there a window that one should be following?
Are generation counters unique per context tag?

>                            +-------+----------+
>                            | Value |  Method  |
>                            +-------+----------+
>                            |   0   | Reserved |
>                            |       |          |
>                            |   1   |    HBA   |
>                            |       |          |
>                            |   2   |    CGA   |
>                            |       |          |
>                            | 3-255 | Reserved |
>                            +-------+----------+

I'm reading on, but what if it is the kind of
a combined HBA and CGA as described in the shim6-hba
draft? Presumably you indicate HBA if the locator
is in the fixed set and CGA if its in the dynamic,
but it would be good to clarify this.

>    This option contains the CGA Parameter Data Structure (PDS).  When
>    HBA is used to verify the locators, the PDS contains the HBA
>    multiprefix extension.  When CGA is used to verify the locators, in
>    addition to the PDS option, the host also needs to include the
>    signature in the form of a CGA Signature option.

The Parameter Data Structure contains more than the
multiprefix extension, e.g., the public key, the
random bits instead of a public key for HBAs, and
any options unrelated to Shim6 that the CGA might
have. I would remove the second sentence above or
reword it to make sure that you really do include
the FULL CGA Parameter Data Structure.

Editorial:

>    included, the packet would become larger than 1280 bytes.Another

s/[.]/. /

>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Next Header  |  Hdr Ext Len  |0|     Type    |Type-specific|0|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Checksum           |                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
>    |                    Type-specific format                       |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Fields:
> 
>    Next Header:   8-bit selector.  Normally set to NO_NXT_HDR (59).
> 
>    Hdr Ext Len:   8-bit unsigned integer.  Length of the Shim6 header in
>                   8-octet units, not including the first 8 octets.
> 
>    P:             Set to zero.  A single bit to distinguish this from
>                   the Shim6 payload extension header.
> 
>    Type:          7-bit unsigned integer.  Identifies the actual message
>                   from the table below.  Type codes 0-63 will not
>                   trigger R1bis messages on a missing context, while 64-
>                   127 will trigger R1bis.
> 
>    0:             A single bit (set to zero) which allows Shim6 and HIP
>                   to have a common header format yet telling Shim6 and
>                   HIP messages apart.

Here I got confused about the two 0's. The first one is P in the list,
the other one is "0". Maybe you need to set one of the zeroes in the
picture to something else (P or R), or add some text to make this
clearer.

Jari

Delivery-date: Tue, 11 Sep 2007 13:40:48 +0000
Cc: [email-masked], shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: AD review draft-ietf-shim6-proto -- sections 1 through 4
Date: Tue, 11 Sep 2007 15:39:30 +0200
To: Jari Arkko <[email-masked]>

Hi Jari,

thanks for the review

w.r.t. you comment, please see below...

El 10/09/2007, a las 19:06, Jari Arkko escribió:

>
> Hi all,
>
> I have started my AD review of this document. Please
> find comments relating to Sections 1 through 4 below,
> along with some tool-generated editorial issues.
>
> Substantial:
>
> Generally speaking I'm happy with the parts that I have
> read so far. The text is easy to read and the reader
> gets an accurate understanding of the Shim6 protocol,
> its capabilities and limitations.
>
> The only substantial question mark that I had was
> here:
>
>> However, the precise
>> interaction between Mobile IPv6 and Shim6 is for further study, but
>> it might make sense to have Mobile IPv6 operate on locators as well,
>> meaning that the shim would be layered on top of the MIPv6 mechanism.
>>
> I worry that there's a circular dependency somewhere between
> IPsec, Shim6, and MIPv6 if they all require something about
> the placement of other layers on top or under them. Or is
> Shim6 capable to be configured to run in different places
> in the stack, e.g., inside and outside a tunnel, depending on
> what the network manager wants?
>
> This may be explained somewhere else...
>

section 5.1 of the applicability draft deals with this specific  
issue, would that address your concerns?

for your convenience, the applicability draft is at http:// 
www.ietf.org/internet-drafts/draft-ietf-shim6-applicability-03.txt

Regards, marcelo

> Editorial:
>>        Figure 31: ICMP error handling with payload  extension header
>
> Extra space.
>
>>   == Unused Reference: '4' is defined on line 5394, but no  
>> explicit reference
>>      was found in the text
>>
>>   == Unused Reference: '5' is defined on line 5397, but no  
>> explicit reference
>>      was found in the text
>>
>>   == Unused Reference: '12' is defined on line 5425, but no explicit
>>      reference was found in the text
>>
>>   == Unused Reference: '24' is defined on line 5464, but no explicit
>>      reference was found in the text
>>
>>   == Unused Reference: '25' is defined on line 5469, but no explicit
>>      reference was found in the text
>>
>>   == Unused Reference: '27' is defined on line 5476, but no explicit
>>      reference was found in the text
> Please add references or remove the documents.
>
>>   ** Obsolete normative reference: RFC 2463 (ref. '5') (Obsoleted  
>> by RFC 4443)
>>
>>   == Outdated reference: A later version (-03) exists of
>>      draft-ietf-shim6-hba-02
>>
>>   == Outdated reference: A later version (-08) exists of
>>      draft-ietf-shim6-failure-detection-07
>>
>>   == Outdated reference: A later version (-03) exists of
>>      draft-ietf-shim6-applicability-02
>>
>>   == Outdated reference: A later version (-08) exists of
>>      draft-ietf-hip-base-07
>>
>>   == Outdated reference: draft-ietf-mobike-protocol has been  
>> published as RFC
>>      4555
>>
> Please use the updated references.
>
>>                        was computed.  See [6]., [8].
> Extra "."
>
>>    A, B, and C are hosts.  X is a potentially malicious host.
>>
>>    ...
>>
>>    CT(X) is a context tag assigned by X.
>
> Wouldn't CT(A) be a more appropriate notation? Or are you
> specifically saying that its the malicious host?
>
> Jari
>

Delivery-date: Mon, 10 Sep 2007 17:07:29 +0000
Date: Mon, 10 Sep 2007 20:06:19 +0300
From: Jari Arkko <[email-masked]>
To:  [email-masked]
CC: shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
Subject: AD review draft-ietf-shim6-proto -- sections 1 through 4

Hi all,

I have started my AD review of this document. Please
find comments relating to Sections 1 through 4 below,
along with some tool-generated editorial issues.

Substantial:

Generally speaking I'm happy with the parts that I have
read so far. The text is easy to read and the reader
gets an accurate understanding of the Shim6 protocol,
its capabilities and limitations.

The only substantial question mark that I had was
here:

> However, the precise
> interaction between Mobile IPv6 and Shim6 is for further study, but
> it might make sense to have Mobile IPv6 operate on locators as well,
> meaning that the shim would be layered on top of the MIPv6 mechanism.
>   
I worry that there's a circular dependency somewhere between
IPsec, Shim6, and MIPv6 if they all require something about
the placement of other layers on top or under them. Or is
Shim6 capable to be configured to run in different places
in the stack, e.g., inside and outside a tunnel, depending on
what the network manager wants?

This may be explained somewhere else...

Editorial:
>        Figure 31: ICMP error handling with payload  extension header

Extra space.

>   = Unused Reference: '4' is defined on line 5394, but no explicit reference
>      was found in the text
>
>   = Unused Reference: '5' is defined on line 5397, but no explicit reference
>      was found in the text
>
>   = Unused Reference: '12' is defined on line 5425, but no explicit
>      reference was found in the text
>
>   = Unused Reference: '24' is defined on line 5464, but no explicit
>      reference was found in the text
>
>   = Unused Reference: '25' is defined on line 5469, but no explicit
>      reference was found in the text
>
>   = Unused Reference: '27' is defined on line 5476, but no explicit
>      reference was found in the text
Please add references or remove the documents.

>   ** Obsolete normative reference: RFC 2463 (ref. '5') (Obsoleted by RFC 4443)
>
>   = Outdated reference: A later version (-03) exists of
>      draft-ietf-shim6-hba-02
>
>   = Outdated reference: A later version (-08) exists of
>      draft-ietf-shim6-failure-detection-07
>
>   = Outdated reference: A later version (-03) exists of
>      draft-ietf-shim6-applicability-02
>
>   = Outdated reference: A later version (-08) exists of
>      draft-ietf-hip-base-07
>
>   = Outdated reference: draft-ietf-mobike-protocol has been published as RFC
>      4555
>   
Please use the updated references.

>                        was computed.  See [6]., [8].
Extra "."

>    A, B, and C are hosts.  X is a potentially malicious host.
>
>    ...
>
>    CT(X) is a context tag assigned by X.

Wouldn't CT(A) be a more appropriate notation? Or are you
specifically saying that its the malicious host?

Jari

Delivery-date: Mon, 10 Sep 2007 11:46:11 +0000
Cc: [email-masked], shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: AD review of draft-ietf-shim6-hba
Date: Mon, 10 Sep 2007 13:44:41 +0200
To: Jari Arkko <[email-masked]>

Hi,

I have done all the changes, except the following, that i think i  
need some help with....

El 09/09/2007, a las 18:14, Jari Arkko escribió:

>
> Hm. I would rather use the same syntax to avoid breakage, but
> the random bits inside. I would suggest finding a suitable
> algorithm ID. It really does not matter what the values are,
> but you need to describe what the encoding is.

The HBA draft at this moment states that:

    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.

According to RFC 3280:

SubjectPublicKeyInfo  ::=  SEQUENCE  {
      algorithm            AlgorithmIdentifier,
      subjectPublicKey     BIT STRING  }

and

AlgorithmIdentifier  ::=  SEQUENCE  {
      algorithm               OBJECT IDENTIFIER,
      parameters              ANY DEFINED BY algorithm OPTIONAL  }

AFAIU, the OI for the AlgorithmIdentifier are dfined in RFC 3279 and  
in particular for RSA:

    The OID rsaEncryption identifies RSA public keys.

       pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                      rsadsi(113549) pkcs(1) 1 }

       rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}

and

       RSAPublicKey ::= SEQUENCE {
          modulus            INTEGER,    -- n
          publicExponent     INTEGER  }  -- e

As i understand it, what you are requesting, is to define a new  
AlgorithmIdentifier value for this case, where the content of the key  
would be a random number.

However, i could only found the values defined in RFC3279. Is there  
any registry where assigned values for AlgorithIdentifier are stored?  
(i mean in order to select one value that doesn't collides with other  
used values and to assign it properly)

Thanks, marcelo

Delivery-date: Sun, 09 Sep 2007 16:16:04 +0000
Date: Sun, 09 Sep 2007 19:14:12 +0300
From: Jari Arkko <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC:  [email-masked], shim6 <[email-masked]>,  "W. Mark Townsley" <[email-masked]>
Subject: Re: AD review of draft-ietf-shim6-hba

Marcelo,

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

Lets do that, then.

> The bottom line is that we are including a random number that is not a
> public key in a field originally reserved for a public key, so at some
> point we will have a semantic problem.
>
> I have checked RFC3280 and RFC3279 and i haven't found values reserved
> for experiments or other usages that could be useful for this (but i
> am not familiar with these specs, so i may be wrong)
>
> At this point, i think it makes little sense to encode the random
> number as SubjectPublicKeyInfo, since as you mention, we will need to
> include an invalid AlgorithmIdentifier. I guess, it is better to
> simply put the 384 random bits of the Extended Identifier directly in
> the Public Key Field in the CGA PDS, than encoding them as public key
> info, since it is less effort for the generation procedure and the
> result is likely to b the same.
>
> So, my suggestion is simply to remove the request to encode the random
> nonce as a SubjectPublicKeyInfo, with a phrasing as follows:
>
>    Second, in the
>    case that the address being generated is an HBA-only address, a
>    random nonce will have to be used as input instead of a
>    valid public key.
>
>
> Also in the HBA genration procedure, the following change is needed
>
>  2. Modifier generation.  Generate a Modifier as a random or
>       pseudorandom 128-bit value.  If a public key has not been provided
>       as an input, generate the Extended Modifier as a 384-bit random or
>       pseudorandom value.  Encode the Extended Modifier value as a RSA
>       key in a DER-encoded ASN.1 structure of the type
>       SubjectPublicKeyInfo defined in the Internet X.509 certificate
>       profile [4].
>
> The last sentence needs to be removed
>
> makes sense?

Hm. I would rather use the same syntax to avoid breakage, but
the random bits inside. I would suggest finding a suitable
algorithm ID. It really does not matter what the values are,
but you need to describe what the encoding is.

>>
>>>    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.
>
> Good point, but i think that the implication of RFC4982 is broader
> than just hash2 generation, since it implies the usage of a different
> hash function for the whole CGA/HBA generation process and also the
> Sec protection mechanism.

Yes.

> I would suggest including a reference to RFC4982 in the beginning of
> the HBA generation and verification procedure. Something like the
> following
>
> 6.  HBA-Set Generation
>
>    The HBA generation process is based on the CGA generation process
>    defined in section 4 of [2].  The goal is to require the minimum
>    amount of changes to the CGA generation process. It should be noted
>    that the following procedure is only valid for Sec values of 0, 1
> and 2.
>    For other Sec values, RFC4982 has defined a CGA SEC registry which
> will
>    contain the specifications used to generate CGAs. The generation
>    procedures defined in such specifications must be used for Sec values
>    other than 0,1 or 2.

Ok.

>
> Similarly for the HBA verification procedure
>
> 7.  HBA verification
>
>    The following procedure is only valid for Sec values of 0, 1 and 2.
>    For other Sec values, RFC4982 has defined a CGA SEC registry which
> will
>    contain the specifications used to verify CGAs. The verification
>    procedures defined in such specifications must be used for Sec values
>    other than 0,1 or 2.

Ok.

>
> In addition, as you mention below, the attack analysis applies only to
> those sec values, so the following rephrassing is proposed (adding
> last couple of sentences)
>
>    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)) in the case of Sec values of 1 and 2. For other
> values,
>    Sec protection mechanisms will be defined by the specifications
> pointed
>    by the CGA SEC registry defined in RFC 4982.

Ok.

>
> Finally, i guess that the 11.4.  SHA-1 Dependency Considerations. need
> also to be updated.
>
> In particular, i would suggest the folllowing rephrasing:
>
> 11.4.  SHA-1 Dependency Considerations.
>
>    Recent attacks to currently used hash functions have motivated a
>    considerable amount of concern in the Internet community.  The
>    recommended approach [13] [14] to deal with this issue is first to
>    analyze the impact of these attacks on the different Internet
>    protocols that use hash functions and second to make sure that the
>    different Internet protocols that use hash functions are capable of
>    migrating to an alternative (more secure) hash function without a
>    major disruption in the Internet operation.
>
>    The aforementioned analysis for CGAs and its extensions (including
>    HBAs) is performed in RFC4982.  The conclusion of the analysis is that
>    the security of the protocols using CGAs and its extensions is not
>    affected by the recently available attacks against hash functions.
>    In spite of that, the CGA specification [2] was updated by RFC4982
>    to enable the support of alternative hash functions.

Ok.

>>
>>>    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.
>>
>
> i see your point.
> actually, this paragraph was aimed for the case where ULAs prefixes or
> other form of prefixes that is not clear thy should be published in
> the DNS are included in the HBA set... makes sense? do you think we
> need to reword the paragraph to make it more explicit?

Ok, but perhaps you should reword it because I did not
get your initial meaning when I did my review. Others may
have the same problem.

>
> In addition, we can add a paragraph with you point:
>
> something like:
>
>    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.
>
> makes sense?

Ok.

>>>    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.
>>
>
> ok, will include the additional sentence:
>
> The actual verification procedure is outside the scope of this
> specification.

Ok.

>
>
>> Editorial:
>>
>
> will correct.
>
> thanks, marcelo
>
>
>

Thanks for your quick response.

Jari

Delivery-date: Sat, 08 Sep 2007 13:07:49 +0000
Cc: [email-masked], shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: AD review of draft-ietf-shim6-hba
Date: Sat, 8 Sep 2007 11:40:09 +0200
To: Jari Arkko <[email-masked]>

Hi Jari, all,

thanks for the review...

I have some questions about the points you make in order to proceed  
with the new version of the draft

se reply in-line

El 03/09/2007, a las 14:24, Jari Arkko escribió:

> Marcelo,
>
> 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."
>

I am not sure it is worth to change the value recommended for trials  
at this stage, since i would expect we are close to publication.

OTOH, I guess that once IANA allocate the final value, we should  
simply drop this sentence, don't you think?

Perhaps we should simply move this sentence to the IANA  
considerations section and add a not "Remove prior publications",  
what do you think?

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

Agree.

>
>>    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.
>

ok

>
>> 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?

good point

The bottom line is that we are including a random number that is not  
a public key in a field originally reserved for a public key, so at  
some point we will have a semantic problem.

I have checked RFC3280 and RFC3279 and i haven't found values  
reserved for experiments or other usages that could be useful for  
this (but i am not familiar with these specs, so i may be wrong)

At this point, i think it makes little sense to encode the random  
number as SubjectPublicKeyInfo, since as you mention, we will need to  
include an invalid AlgorithmIdentifier. I guess, it is better to  
simply put the 384 random bits of the Extended Identifier directly in  
the Public Key Field in the CGA PDS, than encoding them as public key  
info, since it is less effort for the generation procedure and the  
result is likely to b the same.

So, my suggestion is simply to remove the request to encode the  
random nonce as a SubjectPublicKeyInfo, with a phrasing as follows:

    Second, in the
    case that the address being generated is an HBA-only address, a
    random nonce will have to be used as input instead of a
    valid public key.

Also in the HBA genration procedure, the following change is needed

  2. Modifier generation.  Generate a Modifier as a random or
       pseudorandom 128-bit value.  If a public key has not been  
provided
       as an input, generate the Extended Modifier as a 384-bit  
random or
       pseudorandom value.  Encode the Extended Modifier value as a RSA
       key in a DER-encoded ASN.1 structure of the type
       SubjectPublicKeyInfo defined in the Internet X.509 certificate
       profile [4].

The last sentence needs to be removed

makes sense?

>
>>    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.

Good point, but i think that the implication of RFC4982 is broader  
than just hash2 generation, since it implies the usage of a different  
hash function for the whole CGA/HBA generation process and also the  
Sec protection mechanism.

I would suggest including a reference to RFC4982 in the beginning of  
the HBA generation and verification procedure. Something like the  
following

6.  HBA-Set Generation

    The HBA generation process is based on the CGA generation process
    defined in section 4 of [2].  The goal is to require the minimum
    amount of changes to the CGA generation process. It should be noted
    that the following procedure is only valid for Sec values of 0, 1  
and 2.
    For other Sec values, RFC4982 has defined a CGA SEC registry  
which will
    contain the specifications used to generate CGAs. The generation
    procedures defined in such specifications must be used for Sec  
values
    other than 0,1 or 2.

Similarly for the HBA verification procedure

7.  HBA verification

    The following procedure is only valid for Sec values of 0, 1 and 2.
    For other Sec values, RFC4982 has defined a CGA SEC registry  
which will
    contain the specifications used to verify CGAs. The verification
    procedures defined in such specifications must be used for Sec  
values
    other than 0,1 or 2.

In addition, as you mention below, the attack analysis applies only  
to those sec values, so the following rephrassing is proposed (adding  
last couple of sentences)

    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)) in the case of Sec values of 1 and 2. For other  
values,
    Sec protection mechanisms will be defined by the specifications  
pointed
    by the CGA SEC registry defined in RFC 4982.

Finally, i guess that the 11.4.  SHA-1 Dependency Considerations.  
need also to be updated.

In particular, i would suggest the folllowing rephrasing:

11.4.  SHA-1 Dependency Considerations.

    Recent attacks to currently used hash functions have motivated a
    considerable amount of concern in the Internet community.  The
    recommended approach [13] [14] to deal with this issue is first to
    analyze the impact of these attacks on the different Internet
    protocols that use hash functions and second to make sure that the
    different Internet protocols that use hash functions are capable of
    migrating to an alternative (more secure) hash function without a
    major disruption in the Internet operation.

    The aforementioned analysis for CGAs and its extensions (including
    HBAs) is performed in RFC4982.  The conclusion of the analysis is  
that
    the security of the protocols using CGAs and its extensions is not
    affected by the recently available attacks against hash functions.
    In spite of that, the CGA specification [2] was updated by RFC4982
    to enable the support of alternative hash functions.

>
>>    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.
>

i see your point.
actually, this paragraph was aimed for the case where ULAs prefixes  
or other form of prefixes that is not clear thy should be published  
in the DNS are included in the HBA set... makes sense? do you think  
we need to reword the paragraph to make it more explicit?

In addition, we can add a paragraph with you point:

something like:

    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.

makes sense?

>>    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.
>

ok, will include the additional sentence:

The actual verification procedure is outside the scope of this  
specification.

> Editorial:
>

will correct.

thanks, marcelo

Delivery-date: Mon, 03 Sep 2007 12:26:46 +0000
Date: Mon, 03 Sep 2007 15:24:38 +0300
From: Jari Arkko <[email-masked]>
To:  [email-masked]
CC: shim6 <[email-masked]>, "W. Mark Townsley" <[email-masked]>
Subject: AD review of draft-ietf-shim6-hba

Marcelo,

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.

Jari