Subject: [Hipsec] about draft-ietf-hip-mm-04

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 30 Jan 2007 15:52:20 +0100

Hi,

I have some comments about this document.

Disclaimer: this is a first reading of this version of the draft and 
has changed a lot since last time i have read it, so i am probably 
missing some things...

Substantial:

In multiple parts of the document, it seems that there is an assumption 
that mulithoming is about having multiple locators simultaneously, and 
also using them simultaneously (OTOH, in other parts of the document it 
doesn't seems to be the case, so i am kind of confused...) This is 
expressed in the following parts of the document.

For instance in section 3.3.3. it is stated that:

    In general, when multiple locators are used for a session, there is
    the question of using multiple locators for failover only or for
    load-balancing.  Due to the implications of load-balancing on the
    transport layer that still need to be worked out, this draft assumes
    that multiple locators are used primarily for failover.  An
    implementation may use ICMP interactions, reachability checks, or
    other means to detect the failure of a locator.

However, in the next section 3.3.4 it is stated that

    address address31 as well.  However, the use of different source and
    destination addresses typically leads to different paths, with
    different latencies in the network, and if packets were to arrive via
    an arbitrary destination IP address (or path) for a given SPI, the
    reordering due to different latencies may cause some packets to fall
    outside of the ESP anti-replay window.  For this reason, HIP provides

and this type of usage seems the one that governs the mechanisms 
described in the spec.
My point (that i expand below) is that it may be an option to consider 
a simple case for multihoming where the addresses are used sequentially 
and not for load sharing, and in this case, much of the complexity of 
dealing with multiple SPIs would be reduced.
Then define a more complex multihoming case, where load sharing is 
considered and in this case you will need the multiple SPI case.

more details on this....

In section 3.1 it is stated that:

    Such host multihoming
    generally necessitates that a separate ESP SA is maintained for each
    interface in order to prevent packets that arrive over different
    paths from falling outside of the ESP replay protection window.

i fail to understand this part... could you describe a bit more in 
detail why would they fall outside the ESP replay protection window (i 
think it would be useful to include such description in the document in 
any case)
but are you assuming here that multiple addresses will be used 
simultaneously to exchange packets?

I mean, i think that a quite useful reasonable multihoming application 
scenario is where a node has multiple addresses, but it only uses one 
of them to exchange traffic as long this one works. If it detects a 
failure, it moves the communication to an alternative locator pair. 
This is what is needed for fault tolernace. Other applications, like 
using multiple locators simultaneously to exchange packets of the same 
communication seems to go beyond the needs for fault tolernace and 
would provide other different (not so obviously needed imho) features. 
(In particular, in shim6 this capability is not currently provided)

So summarizing, i think that for fault tolernace provision in 
multihoming, it is not needed to use multiple locators to exchange data 
simultaneously. what is needed is to know that there are multiple 
locators, but to use them sequentially, just as in mobility. In this 
case, the difference is when you learn the locator set, rather than how 
you use them. If this is the case, i think that it would be possible to 
have multihoming with a single SPI without having problems with the 
replay protection window. I think this is really important, because all 
this multiple SPI approach seems to present some additional problems 
that i will describe next

Later on in section 3.2.3 it is stated that

    In multihoming scenarios, it is important that hosts receiving
    UPDATEs associate them correctly with the destination address used in
    the packet carrying the UPDATE.

Ok, so this means that:
In the general case where two multihomed hosts are communicating, 
consider host A with N locators and host B with M locators, host A will 
need to send M UPDATe messages (one to each locator of B) containing 
all its locators in each message and including N different SPI. then 
Host B will need to send N UPDATE messages to host A containing all its 
locator and including M different SPIs.

so the result is that for exchanging thier locator sets, A and B will 
need to exchange M+N UPDATE messages and will need to use 2*M*N 
different SPI values, is this correct?

I mean, we need to compare this with the other alternative, which is to 
use just 2 UPDATE messages to exchange the locator sets and use a pair 
of SPIs (one in each direction)

As i mentioned above, i think this is possible if a single locator pair 
is used at the time. I suggest that the draft only deals with simple 
multihoming, but that simple is not the case where one end has 2 
locators and the other just one locator, but that simple is defined as 
the case where the locator pairs are used sequentially, just as in the 
mobility case, just that it happens the they learn it all together.
In this case, i think we can live with a single SPI pair of values (one 
per direction) and all thiss multiple UPDATE message exchange and 
multiple SPI is no longer needed, makes sense?

So in this approach, peers would need to exchange only a single UPDATE 
message in each direction to convey alternative locator information.

The exchange would be

      Multi-homed Host                    Peer Host

               UPDATE(ESP_INFO, LOCATOR, SEQ, [DIFFIE_HELLMAN])
         ----------------------------------->
               UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] )
         <-----------------------------------

At this point, both ends know all the available locator pairs, but the 
reachability test haven't been done yet. However, the reachability test 
is not actually needed until the peer wants to actually use the packet, 
so in the case that there are many locator pairs, doing all the 
reachability test upon the reception of the update message is probably 
not a good idea. Actually the reachability test can be deltayed until 
the peer needs to use the locator pair. In addition, this reahcbaility 
test can be use to actually check the reacbaility of the locator pair 
when the peer wants to use it. (i mean, making the reachability test 
upon the reception of the UPDATe message is useful for preventing 
flooding attacks, but is not so useful for determining whether the 
locator pair is working, becasue the peer will not use the locator pair 
inmediatelly)

So, i would suggest that the ECHO request/reply packets are used as a 
basic way to determine if the locator pair is working, and that this 
verification is only performed when the preferred locator pair stops 
working (or when the peer wants to start using a new locator pair for 
whatever reason) At this point the echo request reply can be used to 
test reachability in order to select a new alternative locator pair 
that is working. this i think would also be compatible with using a 
single SPI, since you would only send a limited set of packets through 
alternative paths, whcih shouldn't affect the replay protection window 
so much (i am guessing here....)

So my suggestion is: define a simple multihomed case for sequentially 
used locator pairs, where
- Use a single SPI pair for all locator pairs
- Use a single pair of UPDATE messages
- Perform the ECHO request reply only when the new locator pair will be 
used

Semi substantial:

In section i it is stated that:

    Preferred locator. A locator on which a host prefers to receive data.

This is strange... i mean the locator where a node receives traffic to 
doesn't seem to be so relevant as the receiver doesn't even look at the 
locators in the incoming packet, but just to the SPI to perform the 
demux. I, mean, as long as the locator has been assigned to the host 
and the SPI is the correct one, the particular locator doesn't seem to 
be relevant. OTOH, what it seems to be relevant, is the locator that a 
peer uses to send traffic. Of corse, a receiver may express to the peer 
what locator it prefers to receive traffic, but at the end of the day, 
is the choice of the sender which one to actually use to send the 
traffic. This is especially true in the multihoming case, where the 
sender may have multiple valid locators to send traffic to. So, maybe 
including something from the senders perspective would be good here, 
like the preferred peer locator and the preferred local locator

In section 3.1 it is stated that:

    Finally, consider the case when a host is multihomed (has more than
    one globally routable address) and makes these multiple addresses
    available for use by the upper layer protocols, for fault tolerance.

Not sure about the phrasing of this sentence, the addresses are not 
available for the upper layers, since the multiple address are 
transparent to the upper layers (this is what all this is about, 
right?)
So i would suggest to rephrase this, saying that the addresses are 
available for the HIP ayer to be used as alternative locators or 
soemthing in this line.

In section 3.2 it is stated that:

    However, some implementations may want to experiment with
    sending LOCATOR parameters also on other packets, such as R1, I2, and
    NOTIFY.

I am not sure that R1 makes much sense... i mean, this is probably part 
of the initial contact problem i.e. when sending the I1, the initiator 
needs to know multiple locators in case one has failed. So including 
them in R1 doesn't seem to help much at that point imho. OTOH, 
including them in R2, would result in having them already available for 
that communication.

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec