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

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 2 Feb 2007 13:35:43 -0800

Marcelo,
Thanks for the detailed review; below are some inline responses: 

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Tuesday, January 30, 2007 6:52 AM
> To: Henderson, Thomas R; HIP
> Subject: about draft-ietf-hip-mm-04
> 
> 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.
> 

Perhaps this is a terminology issue; if the addresses are used
sequentially, is this not the same as the mobility case (even though the
device may not be mobile, but the language in the draft governing the
mobility case would cover it)?

i.e., if there was some description that by "mobile" we mean that we are
talking about the case where multiple addresses on an interface are used
sequentially, and that some multihoming scenarios also fit into this
category, would it solve this issue for you?

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

Yes, if there are multiple addresses used simultaneously on the same
SPI, particularly with multiple interfaces, there seems to be a
possibility that, depending on how the ESP sliding window (RFC 4303, Sec
3.4.3) is implemented and configured, reordering due to multiple paths
may cause packets to be rejected.

Now, in IP routing, paths may change, and one would hope that ESP
sliding window sizes would be robust to such typical path changes.  I
don't know for sure whether multihoming path reordering would result in
larger reordering events than what one would see due to routing, but it
is conceivable that it may be larger if we are considering
multihoming/load balancing across multiple interfaces using different
access link technologies.  This is the reason that the recommendation
for multiple SAs was inserted; namely, that window sizes configured to
survive typical path rerouting may not be sufficient for multiple
interface multihoming.  Another alternative solution would be to
increase the ESP window for these types of configurations; this would be
simpler to support at the possible expense of more vulnerability in the
window. 

Would this change help in Section 3.2.3:

   To avoid problems with the ESP anti-replay window, a host SHOULD use
   a different SA for each interface or address used to receive packets
   from the peer host.
                    ^^
                   , when multiple locator pairs are being used
simultaneously rather than sequentially.

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

I agree that it is simpler to avoid multiple SPIs, and perhaps that is
what people will do in practice, but we were just trying to cover the
case where it was possibly needed.  Perhaps we are a little too
aggressive in describing examples where all of these SAs become active
when, in practice, most need not be.

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

There are possibly more messages; if A and B wished to establish a full
mesh of SPIs between their respective locator sets, there could be up to
O(N*M) UPDATE handshake exchanges and O(2*N*M) SPI values.  We were
trying to define the protocol so as to not preclude this, but
operationally it is likely that the above would be overkill, and
probably N and M are small numbers.

If host A wishes to provide host B with N locators to choose from, and
likewise B wants to provide A with M locators to choose from, it is a
matter of policy as to which pairs of addresses that A or B care to form
SPIs on, but it is recommended that for each such pair, an UPDATE
handshake is done across that pair of addresses.  This is mainly because
the UPDATE packet conveys SPI information that a policy-enforcing
middlebox may want to inspect, and the use of different locator pairs
may cause different middleboxes to be traversed.  This is why that text
is written as it is; if you get an UPDATE to a particular destination
address, then you should send the response UPDATE by reversing the
addresses, regardless of whether that is the preferred locator for the
peer.

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

I think what you are arguing for is more explicit decoupling of UPDATE
function of conveying locator sets from UPDATE function of setting up
SPIs between them, right?  Note that each LOCATOR parameter conveys a
complete locator set.  I think that the protocol supports what you are
asking for, but the text on how to use it that way is missing from the
draft.

Much of this draft was written before shim6/REAP had crystallized.
Maybe it is worth taking a pass through the multihoming section to try
to align it with what Marcelo suggests.  I would be willing to take a
stab at it, but does the WG support doing so in principle?

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

Consider the case where you have multiple heterogeneous interfaces and
one is preferred for bandwidth or cost reasons.

> 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

I don't think the draft precludes it; preferred local source locator is
a matter of source policy and not part of the protocol exchange.

I wouldn't object to stating something along the lines above that there
are policy decisions that affect how packets are sent, and these include
decisions on both what locator to tell the peer is preferred destination
locator, and also what locator/interface to use as the source.  
 
> 
> 
> 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.

I agree with your clarification and will change it unless anyone
discusses further.

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

The thinking was that there may be a use case where the responder wants
to shift I2/R2 exchange onto a different interface, without necessarily
updating the DNS or rendezvous server to do so.

Thanks again for the review,
Tom

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 3 Feb 2007 14:45:11 +0100

> category, would it solve this issue for you?

i don't think this would be enough...

There are two sides of this:

First, the multihoming case has some substantial cases that the case of 
mobility essentially, because in the mobility case the assumption is 
that the node learns one address at the time, so the sequential usage 
of the addresses is just a natural concequence of this. In the 
multihoming case, the node may learn all the addresses in a single 
update message but it can choose to use them sequentially essntially 
because this all that is needed for fault tolerance.
So, in the draft these cases are clearly differentiated and the 
mobility case seems to only cover the case where the node learns one 
address at the time. At least is not clear at all to me from the 
reading of the draft that the mobility case covers the case of 
sequential usage of addresses in multihomed cases.

Second, it may be required some different processing in the case of 
multihoming (not very different though) In particular, in case you 
learn all the addresses in a single update, you need to think about how 
to perform the verification. I guess that a single HMAC/signature would 
protect all the addresses, but i don't think it is needed to perform 
the echo request verification for all the addresses contained in the 
UPDATE message inmediatelly after the reception of the message. I mean, 
this verification has a cost (packet exchange) and it may not be 
required (since you may not need to use the address never) This is 
again different from the mobility case, where when a node learns a new 
address, it will inmediatelly use it, since it is the only one it has. 
Moreover, in the multihoming case, it is highly likely that the node 
will need to perform the echo request reply exchange just before 
actually using the new address, since it will want to verify the the 
address is working.

So, i would suggest to include a new section that describes how to 
support sequential usage of addresses in multihoming. The tools would 
be very similar than the case of mobility i agree, but i really think 
the draft would be much clearer if this is explicitly described 
including the considerations about the different moments the addresses 
are learnt  and used in multihoming.

I can provide text for this if you want....

> simultaneously rather than sequentially.

yes, very much

> case where it was possibly needed.

I think it is perfectly okey to cover this case, so when people try to 
use multiple locators simultaneously, this is already covered in the 
draft. So, actually i am not suggesting to remove anything, just to add 
additional text describing more in detail the simpler case where the 
addresses are used sequentially (but learnt simultaneously)

>  Perhaps we are a little too

Well, actually in the simple case described, the text is a bit 
confusing, since on one hand multiple SPIs are used, but it is 
reccomended that addresses are not used simultaneously.

> asking for, but the text on how to use it that way is missing from the

agree, i think the protocol messages described are all that is needed 
(what i think is missing is a description of the sequential case and 
for that case explicitly not reccomend the usage of mutliple SPIs)

> stab at it, but does the WG support doing so in principle?

as i said above, i am willing to help you with this

> one is preferred for bandwidth or cost reasons.

agree

> locator, and also what locator/interface to use as the source.

my point was that it may make sense to also define the local preferred 
locator and also the peer preferred locator

> updating the DNS or rendezvous server to do so.

i see

thanks, marcelo

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 5 Feb 2007 08:39:36 -0800

> Sent: Saturday, February 03, 2007 5:45 AM
> To: Henderson, Thomas R
> Cc: HIP
> Subject: Re: about draft-ietf-hip-mm-04
> 
<snip>
> I can provide text for this if you want....

I think it would be helpful to propose this new text; I would think that
it would be an agreeable and useful extension of what we have already.

There will be a few other changes due the secdir review of the draft; I
think that the -05 version of the draft can propose the changes due to
this and also the reviews ongoing presently.

Thanks,
Tom

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 6 Feb 2007 17:57:13 +1300

> this and also the reviews ongoing presently.

However, let's not forget that the reason the draft turned out this  
way is because there's a known issue with using the same SPI in quick  
succession going from a very fast link to a very slow one... namely,  
that the windows in both ESP and TCP interact really badly in that  
case.  So using separate SPIs is rather required.  I don't object to  
text describing how to use this for multihoming, far from it, but the  
multi-SPI solution really is necessary.

Andrew

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 6 Feb 2007 09:18:17 +0100

El 06/02/2007, a las 5:57, Andrew McGregor escribió:

> succession going from a very fast link to a very slow one...

but it could happen the very same thing in the mobility case, right? I 
may even say that this is more likely since in mobility the different 
types of links may differ greatly in terms of bandwidth.

Actually, for the multihoming case, the problem is already there even 
if you don't use multiple locators. I mean if you are using BGP type of 
multihoming, it may well be the case that you change the exit link in a 
multihomed site using the same address and then you would face the 
exact same problems that you are describing, right?

>  namely, that the windows in both ESP and TCP interact really badly in 
> that case.  So using separate SPIs is rather required.  I don't object 
> to text describing how to use this for multihoming, far from it, but 
> the multi-SPI solution really is necessary.
>

as i see it, multiple spi is a must if you want to use multiple 
locators pairs simultaneously. If you want to use them sequentially i 
would say a MAY, since it is the same situation that we have here in 
BGP based multihomed sites even if you use a single locator pair for 
the hip communication, agree?

Regards, marcelo

---

From: Andrew McGregor <[email-masked]>
Date: Tue, 6 Feb 2007 21:21:46 +1300

On 06/02/2007, at 9:18 PM, marcelo bagnulo braun wrote:

>
>
> but it could happen the very same thing in the mobility case,  
> right? I may even say that this is more likely since in mobility  
> the different types of links may differ greatly in terms of bandwidth.

A dramatic difference in latency might be worse than a bandwidth  
change, but yes.

>
> Actually, for the multihoming case, the problem is already there  
> even if you don't use multiple locators. I mean if you are using  
> BGP type of multihoming, it may well be the case that you change  
> the exit link in a multihomed site using the same address and then  
> you would face the exact same problems that you are describing, right?

Exactly.

> locators pairs simultaneously. If you want to use them sequentially  
> i would say a MAY, since it is the same situation that we have here  
> in BGP based multihomed sites even if you use a single locator pair  
> for the hip communication, agree?

Yes, I suppose.  I might suggest SHOULD rather than MAY, as that  
implies there better be a good reason not to, rather than that the  
feature is simply optional.

Andrew