Re: New issue 16: No packets from other end?

sorry for the late reply.

I agree that while the IP stack (MIP6 or multi6) can determine
if there is a pair of addresses that the IP stack can use, we
still need an IKE message to figure out if the IKE endpoints
have a pair of addresses that they can use. and if the IP
stack (or a policy on the mobile node) tells MOBIKE to use a
particular address, that address should be tried first always.

Vijay

Tero Kivinen wrote:
> Vijay Devarapalli writes:
> 
>>>- In general, lower-layer mechanisms cannot tell whether pair
>>>  (Ai,Bj) provides connectivity between the IKEv2 endpoints:
>>>  only an IKEv2 message exchange can tell that.
>>
>>totally disagree with this particular statement. assuming the IP
>>stack is the lower layer (with might include MIP6/MULTI6), why
>>would MOBIKE be able to figure out something the IP stack couldnt?
> 
> 
> Because MOBIKE is the only one that can really say if there is
> connection that is good enough for him. For the IP point of view the
> connection between two IP-addresses might work even when there is NAT
> between, which eats all UDP port 500/4500 packets. For MOBIKE point of
> view the connection is broken. 
> 
> 
>>UDP is a transport protocol on top of IP, right?
> 
> 
> yes. And TCP is over IP, and even when TCP works it does not give us
> any indication that UDP will really work. Also even if UDP for port x
> works, it does not say anything whether UDP on port y will work. This
> is because of firewalls, nats and similar things. Also sending one
> ICMP message might make IP layer to think that the connection is
> broken, and we propably do not want to allow that easy DoS attacks.
> 
> I think MOBIKE should get use and try to get as much information from
> outside as possible, but in the end it still needs to test the
> possible address pairs by itself to get positive feedback that the
> address pair works.
> 
> The other layers can give lots all kind of hints, and most likely it
> can give quite reliable negative feedback, i.e. it can say that this
> address cannot work anymore as the interface used was removed from the
> machine, or the DHCP server gave me new address etc. We can belive
> some of that information but it might also give information saying
> this IP-address is not working, as I got ICMP host unreachable back
> to my ICMP ping message, and we propably should not belive that
> information.