Re: FW: Marcelo's review of mobike protocol

El 13/10/2005, a las 14:27, Tero Kivinen escribió:

> Jari Arkko writes:
>> 2. As i understand it, as currently defined, mobike does not supports
>> multiple address pairs simultaneously in a given SA, right? Moreover, 
>> as
>> i read it, all the IPSec SAs created with the same IKE SA have the 
>> same
>> address pair right? If any of these are so, IMHO this should be
>> explicitly noted in the document, since it would imho have two 
>> immediate
>> consequences:
>> 2.1 No load sharing, load balancing, traffic engineering or
>> policing/preference setting would be supported, like distributing
>> different traffics through different address pairs/links, which should
>> be noted imho
>> 2.2 No unidirectional paths are supported i.e. if a address pair is
>> working in one direction and another address pair is working in the
>> other direction, this cannot work, which should be noted explicitly 
>> too
>> in the spec imho.
>
> Most of those things should be covered by the design document, but
> short mention in the introduction could be good thing.
>
>> 3. The previous point brings me to this point, which is about ingress
>> filtering compatibility. There is no mention to ingress filtering
>> comaptibility here. As you know, when multiple addresses are 
>> available,
>> packets may be dropped by incompatibility between ingress filters and
>> the selected source address. This document does not considers this as 
>> a
>> problem. Becuase of ingress filters, many unidirectional paths may
>> result (packets are dropped when flowing in one direction). However, 
>> as
>> i understand it, mobike does not supports unidirectional paths (since
>> the same address pair is used in both directions). So, my point is 
>> that
>> in a case where no ingress filtering compatibility mechanism is 
>> provided
>> and because no unidirectional paths are supported, the mobike protocol
>> is likely to perform poorly in this scenario. I guess that at least 
>> you
>> should mention this, if not fix it.
>
> There should not be problems with the ingress filters, as we always
> use the source address associated to the given interface when sending
> packets out. I.e. if we have two interfaces A and B, having IPa and
> IPb,  when we send packets out using IPa we always select interface A.
> The network connected to the interface should allow IPa to pass
> through it as it is IP address given by the network to the host for
> that interface. Implementations might need to do specific things to
> bypass routing of those packets (using default route or similar) to
> make use they are really sent out from the host using proper
> interface.
>

yes in this case there shouldn't be problems with ingress filters. 
However, as i understand it, it is expected that a common multihoming 
scenario is that multiple PA address blocks are assigned to a 
multihomed site (one per isp serving the site), so that there will be 
multiple global addresses assigned to each interface connected to the 
multihomed site.
In this case, selecting the egress interface doesn't help you selecting 
among the multiple addresses assigned to that interface.
However, you still may have problem with ingress filters because each 
address has been assigned by a different ISP, implying that if ingress 
filters are in place, each isp will only route those packets that 
contain the prefix delegated by the particular isp in the source 
address of the packet. hence, we may have ingress filters 
incompatibility issues, so unidirectional paths may be quite frequent 
if no ingress filters compatibility mechanisms are in place (for more 
about this check draft-huitema-shim6-ingress-filtering-00.txt


>> 4. Establishment of the initial IKE session. No reference is made 
>> about
>> how the initial contact between the two parties is made. I mean, in 
>> case
>> that both have multiple addresses, and that some of them are not
>> working, the initial contact may not be trivial. Maybe this is out of
>> the scope of mobike, but current specs don't support this scenario, so
>> maybe it would be worth noting it.
>
> I think the assumption is that the initiator knows the IP address (or
> IP-addresses) of the other peer before the connection is even
> initiated, thus MOBIKE will simply try the different addresses trying
> to find working one.
>

i guess that this at least needs to be specified i.e. that mobike will 
try with different addresses.... question: is mobike going to retry 
using only different destination addresses or it will also try with 
different source addresses? i guess it makes sense to try with 
different source addresses as well, in particular, with all the 
possible combinations src and dst addresses available.
However, while it may be quite common that a node retires with 
different dest addresses (hey, rfc3484 says that a node SHOULD do it) 
currently, it is not usual AFAIK retrials with different source 
addresses, hence why mobike should explicitly mention it if you want 
this imho

>>
>> 5. In the document, it seems that an important design choice that was
>> made was that (section 3.1)
> ... [about the initiator selects approach]
>
> That discussion about why that approach was selected and what it
> causes does not belong to the protocol document. It should be
> something that is in the design document.
>

right
however, my intention was somehow different than the rationale for this 
choice is included in the doc.

my point was that:
- as i understand it, when designing the protocol, the wg decided to 
assume this asymetrical roles, where the initiator is kind of 
responsible for selecting addresses and so on.
- based on this choice, the protocol was designed.
- now, once that protocol is ready, the assumption is still there.

My point was to identify how this asumption really affects the 
resulting protocol and see if it is still needed.

As i see it, the protocol is quite symetrical and there only a few 
corner cases where this assumption is needed. In particular, for
- simultaneous movement
- responder behind a nat.

OTOH, there are a couple of special cases described in the protocol, in 
order to allow the responder to change addresses to deal with some 
situations.

So my question is:
wouldn't it be easier/simpler to define a symetrical protocol stating 
that simultaneous movement and both aprties behind nat situations are 
not supported.
If this can be done, the protocol would be more general and there 
wouldn't be needed those special situations where one of the parties 
need to do special operations (responder changing addresses)

>> 11. In section 4.5. the NO_ADDITIONAL_ADDRESSES notification is
>> presented. As i understand it, this is the only way to delete 
>> addresses
>> from the address set, right?
>> This is kind of twisted, i think. I mean, if a node wants to delete 
>> one
>> address because is no longer available it, must:
>> - delete all the addresses using a NO_ADDITIONAL_ADDRESSES 
>> notification
>> message
>> - add other addresses with a ADDITIONAL_ADDRESSES notification
>> is this so?
>> If yes, i think this should be clearly stated imho (at least that the
>> NO_ADDITIONAL_ADDRESSES notification serves to delete addresses)
>
> No, I have not understood that section that way. I assumed that the
> new list of addresses (ADDITIONAL_ADDRESSES) always overwrites the
> whole previous list. I.e. it is not incremental update, but it is full
> list every time. In some cases where you have only one IP-address, the
> ADDITIONAL_ADDRESSES notify would not be there, and you need to have
> some way to tell that there is no other addresses than the one that is
> used in the IP-headers of this packet.
>

ok, i think we have identified an important element here: my reading of 
this was that additional addresses are incremental to the set already 
available.

I think that it would be very important to explictly state whether the 
addresses in the additional address is a complete set or an incremental 
update.

>> 12. In section 4.6 it is stated that:
>>
>>    By default, the return routability check SHOULD be done before
>>    updating the IPsec SAs.  In environments where the peer is expected
>>    to be well-behaved (many corporate VPNs, for instance), or the
>>    address can be verified by some other means (e.g., the address is
>>    included in the peer's certificate), the return routability check 
>> MAY
>>    be omitted or postponed until after the IPsec SAs have been 
>> updated.
>>
>> I am not sure that the example of the certificate is a good example...
>> what if the certificate is self signed? (i don't know if those are
>> supported) but in any case, i don't know how simple is that 
>> certificates
>> can prove address ownership (this depends of the checks performed by 
>> the
>> CA about address ownership)
>
> If the certificate is self signed, and it is trusted by the recipient
> there is no problem. The basic idea is that in the VPN case where
> multiple sites are connected together with VPN gateways each having
> one or two addresses, each VPN gateway can have certificate which
> lists the IP-addresses they have. The VPN gateways are not going to
> get new address on the fly, thus they can use IP-addresses from the
> certificates. Also the most common case of road warrior will probably
> be that the gateway is authenticated with certificate and the client
> is authenticated with some EAP method. In that case it would be
> useless for clients to do return routability to the server's second
> address, when the first address happen to go down.
>

ok

regards, marcelo

> -- 
> [email protected]
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>