Re: AD review of draft-ietf-shim6-proto -- sections 7.18 through 14

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

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