Re: v4 CoA and route optimization [Re: [Mip6] draft-solimananddraft-wakikawa]

Pekka Savola wrote:
>> Yes, but it's impossible to just send an enhanced BU to HA without 
>> first setting up some state on GW and MN about the v4/NAT traversal.  
>> The state on MN, NAT and GW must be synchronized somehow and doing it 
>> with only one message MN->NAT->GW is impossible, I mean some 
>> acknowledgement is necessary.
> 
> I'm not sure what you mean.  MN can send a message directly to the HA 
> (or tunnel server, if applicable), going through the NAT; this also 
> (implicitly) punches a hole in the NAT.  The HA (or tunnel server) 
> naturally acknowledges the set up of the tunnel, but if the 
> acknowledgement comes from the same UDP port (etc.), it will use the 
> already established NAT state.

YEs... somehow... "Punching" a hole in the NAT boxes may not be 
immediately successful, several probes may be necessary, in which case 
the successful probe's characteristics should be acknowledged back to 
the MN in order for it to know what to use starting then.

>>> However, if the client knows in advance which encapsulation type to
>>> use, it can just send in a request, piggybacking the data, and if the
>>> tunnel is set up, the tunnel server can immediate forward the data
>>> and set up the tunnel, otherwise reject setting up the tunnel and
>>> discard the data.
>>
>>
>> To this scenario I object with the security aspects.  If the tunnel 
>> server puts up a tunnel whenever a Client requests it, and if they 
>> don't share a secret, DoS attacks are obviously possible.
> 
> 
> Obviously the client can include whichever secret it wants.  Too bad 0.5 
> RTT doesn't allow a challenge-response negotiation, so it's effectively 
> a shared, plain-text secret.
> 
> There are other options, though.  See 
> draft-parent-v6tc-protocol-exploration-00 section 2.1.2 for an example 
> how SEND could be used in this context securely without any extra 
> roundtrips.
> 
> But this discussion is probably going to too much detail at this point, 
> so I guess we should take the followups off-list(s).

Ok, let me stop here, thanks for the reply.

Alex

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6