El 02/02/2007, a las 22:35, Henderson, Thomas R escribió:
>
> 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?
>
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....
>> 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.
>
yes, very much
>>
>> 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.
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
> aggressive in describing examples where all of these
SAs become active
> when, in practice, most need not be.
>
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.
>>
>> 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.
>
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)
> 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 said above, i am willing to help you with this
>
>>
>> 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.
agree
>
>> 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.
>
my point was that it may make sense to also define the local
preferred
locator and also the peer preferred 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.
>
> 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.
>
i see
thanks, marcelo
> Thanks again for the review,
> Tom
>
_______________________________________________
Hipsec mailing list
Hipsec lists.ietf.org
https:/
/www1.ietf.org/mailman/listinfo/hipsec
|
