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

On Wed, 6 Apr 2005, Alexandru Petrescu wrote:
>> You also lose at least 1 RTT for signalling.
>
> 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.

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

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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