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

From: [email-masked]
Date: Mon, 4 Apr 2005 09:50:37 -0700

>  > Note that AFAIK, NAT traversal between the bidirectional 
>  > MN-HA tunnel 
>  > is likely going to be rather simple (if keepalives are 
> considered OK 
>  > in the scenario; as Hesham points out, they might be completely 
>  > unacceptable in some sceanrios [but that's why it could be 
>  > possible to 
>  > turn them off it there is no NAT on the path]).
> 
> => Exactly right. This is why in draft-soliman the choice was made
> to not include the NAT traversal by default. It would be nice 
> if something can be added/removed when needed. For instance, 
> when managing local mobility there is no need for NAT traversal, 
> when managing global mobility you might need it. 
> I haven't read doors/teredo in a looong time and can't remember
> if there is anything that can be used to turn this on/off.

draft-wakikawa specifies one mechanism to detect NATs based 
on IKEv2. and the NAT traversal mechanism can be used only 
when a NAT is detected. see the draft. so for local mobility, 
for e.g. if no NAT is detected between the MN and the MAP, 
NAT traversal is not used. if a NAT is detected between the 
MN and the HA, NAT traversal is used.

we have two options for NAT traversal. if all traffic through 
the tunnel is protected by ESP, then we use RFC 3948. if ESP
is not used, then IPv6-in-UDP-over-IPv4 tunneling is used.

and in the slides we presented at the IETF, we had a question
for the WG, if we need to come up with another NAT detection
mechanisn based on MIPv6 (similar to what MIPv4 does), but
we didnt get any response. if the WG thinks we need one based
on MIPv6, I have an idea on how to do it.

Vijay

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Apr 2005 14:04:09 +0200

[email-masked] wrote:
> draft-wakikawa specifies one mechanism to detect NATs based on IKEv2.

Vijay, I'm not sure NATs need to be detected.  I'm not sure it's 
necessary to impose the use of IKEv2 in order to detect being behind a NAT.

Being behind a NAT or not can be detected very simply by the GW by 
checking the src address and some address that MN puts in the payload.

> we have two options for NAT traversal. if all traffic through the
> tunnel is protected by ESP, then we use RFC 3948. if ESP is not used,
> then IPv6-in-UDP-over-IPv4 tunneling is used.

I kind of agree with this.  I was thinking though that if the outer v4 
packet is not ESP'ed then the inner v6 packet could be ESP'ed, or 
alternatively - if UDP tunneling is used - RFC 3948.  At which point it 
would make no sense to use both RFC 3948 _and_ RFC 3776, because that 
would give double ESP encapsulation...

> and in the slides we presented at the IETF, we had a question for the
> WG, if we need to come up with another NAT detection mechanisn based
> on MIPv6 (similar to what MIPv4 does), but we didnt get any response.
> if the WG thinks we need one based on MIPv6, I have an idea on how to
> do it.

How?

Alex

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Apr 2005 15:19:30 +0300 (EEST)

On Wed, 6 Apr 2005, Alexandru Petrescu wrote:
> Vijay, I'm not sure NATs need to be detected.  I'm not sure it's necessary to 
> impose the use of IKEv2 in order to detect being behind a NAT.
>
> Being behind a NAT or not can be detected very simply by the GW by checking 
> the src address and some address that MN puts in the payload.

That assumes that you have a separate signalling plane (e.g., MIPv6 
binding updates) apart from the data plane. You also lose at least 1 
RTT for signalling.

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.

One 1.5 RTT's vs 0.5 RTT to forward user's packets and some amount of 
protocol complexity may not be an issue, of course.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Apr 2005 14:38:23 +0200

Pekka Savola wrote:
> binding updates) apart from the data plane.

Yes, a separate signalling plane.

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

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

Alex

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Apr 2005 16:14:03 +0300 (EEST)

On Wed, 6 Apr 2005, Alexandru Petrescu wrote:
> 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.

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Apr 2005 16:00:42 +0200

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

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.

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