Re: FW: Marcelo's review of mobike protocol

marcelo bagnulo braun writes:
> > 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.

I do not think that will be the case of the roaming laptop case, i.e.
the GPRS, WLAN and fixed ethernet links all give out exctly one
IP-address to the connected interface, and you are only supposed to
use that IP-address through that interface to which it was given to.

> 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

This could be the case in the multihomed VPN case. Note, that MOBIKE
should still work perfect, if that unidirectional path does not work
(i.e. packets does not get back when IP-addresses are reversed), then
that address pair is not used, and we finally end up selecting address
pair which does not have that problem with ingress filters.

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

If it has multiple IP addresses associated to the IKE SA (even before
it is created) then it should try all combinations of them through the
normal IKE SA retransmission policy.

> 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

Yes, might be good idea explicitly mention this anyways.

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

With fully symmetric protocol we cannot really support NAT-T at all.
Neither for initiator or responder, as with symmetric protocol there
is no difference in that.

The end host which is behind NAT must take asymmetric action and fix
the situation which its addresses change, as the other end cannot send
packets to the new address before host behind NAT has done so. This
means that the protocol will always be asymmetric if NAT-T is desired.

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

This was quite extensively discussed on the list and meetings before
the selection of the "initiator decices" was done. We did try few
protocols that tried to be symmetric, but they did get much more
complicated immediately when NAT-T was added. Actually my initial
protocol was one of those symmetric ones but it didn't support any
NAT traversal.

I still think all the discussion about this belongs to the design
draft. 

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

Agree on that. (and it is complete set).
-- 
[email protected]