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

[Jari Arkko <jari.arkko@piuha.net>]

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