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

From: [email-masked]
Date: Thu, 7 Apr 2005 10:02:16 -0700

Pascal,

RFC 3775, 3776 and 3963 all use IPsec by default for
setting up security associations between the MN/MR and 
the HA. once draft-ietf-mip6-ikev2-ipsec is approved, I 
believe IKEv2 will become the default mechanism for 
setting up security associations between the MN/MR and 
the HA.

so what are you objecting to? the use of IKEv2 or the use
of IKEv2 for detecting NATs? 

IKEv2 has a NAT detection mechanism. and if MN/MR and 
the HA use IKEv2 to set up security associations, then it
is natural to use IKEv2 to detect NATs also.

if the WG feels we need another MIP specific mechanism
for detecting NATs, we can work on it. we had that 
question on the slides presented at the last IETF meeting.
there wasnt any feedback at that time.

Vijay

> -----Original Message-----
> From: ext Pascal Thubert (pthubert) [mailto:[email-masked]]
> Sent: Thursday, April 07, 2005 12:21 AM
> To: Devarapalli Vijay (Nokia-NRC/MtView);
> [email-masked]
> Cc: [email-masked]
> Subject: RE: v4 CoA and route optimization [Re:[Mip6]
> draft-solimananddraft-wakikawa]
> 
> 
> 
> 
> | -----Original Message-----
> | From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> | [email-masked]
> | Sent: Wednesday, April 06, 2005 7:42 PM
> | To: [email-masked]
> | Cc: [email-masked]
> | Subject: RE: v4 CoA and route optimization [Re:[Mip6] draft-
> | solimananddraft-wakikawa]
> | 
> | > > 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?
> | 
> | let the WG first decide on whether IKEv2 is sufficient for
> | detecting NATs when the MN and the HA run IKEv2 between
> | them. if the WG things we need another MIP specific mechanism
> | we will get to this later. this discussio will only be a
> | distraction now.
> | 
> Hi Vijay:
> 
> I would not approve a solution that makes a dependency to IKEv2 for
> traversing NATs, unless IKEv2 becomes universal for MRHA. At 
> the moment,
> the relation between the key negotiation and IPv4 traversal mechanisms
> seems pretty loose so I would not forcefully tie them, even if it
> actually works.
> 
> I'd rather have a modular approach in the solutions that we 
> put in place
> for the problems that we want to solve.
> 
> But maybe I missed what you really mean here. Could you clarify?
> 
> Pascal
> 

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Apr 2005 21:12:06 +0200

[email-masked] wrote:
> Pascal,
> 
> RFC 3775, 3776 and 3963 all use IPsec by default for setting up
> security associations between the MN/MR and the HA. once
> draft-ietf-mip6-ikev2-ipsec is approved, I believe IKEv2 will become
> the default mechanism for setting up security associations between
> the MN/MR and the HA.
> 
> so what are you objecting to? the use of IKEv2 or the use of IKEv2
> for detecting NATs?
> 
> IKEv2 has a NAT detection mechanism. and if MN/MR and the HA use
> IKEv2 to set up security associations, then it is natural to use
> IKEv2 to detect NATs also.
> 
> if the WG feels we need another MIP specific mechanism for detecting
> NATs, we can work on it. we had that question on the slides presented
> at the last IETF meeting. there wasnt any feedback at that time.

Vijay, excuse me interfering in your discussion with Pascal.

Thanks for posting this, it is important to remind that all Mobile IPv6 
RFCs rely on IKE to set up the MN-HA SAs.  I must also say that I am not 
very familiar with IKE, and even less with IKE's NAT detection features 
and nothing about IPv6 IKEv2.

ALso, please let me point out that if IKEv2 for v4 is capable of going 
through all sorts of NATs, and if using IKEv2 for v4 does not involve 
exchanging too many messages every time MN changes its v4 Address, then 
I think I support it, instead of MIP4's NAT traversal scheme.

However, may I also say that the ISAKMP (that I use with my corporate 
VPN, probably similar to yours) (1) uses a 10-message initial exchange 
and (2) uses a fixed outgoing port number for UDP which seems to be 500.

Shortening the 10-message exchange is probably seen by you to be done 
with RFC3776  or with draft-ietf-mip6-ikev2 (I'm not sure); but both 
these drafts are v6-related; or, the NAT traversal should be v4-related, 
and I am not aware of a requirement to use IKE between MN and HA for 
MIP4, neither am I aware of a way to shorten the 10-message v4 IKE 
exchange.  Enlightenment on this issue would be beneficial.

For the second issue (UDP port 500) I am not sure that all wireless 
telecom operators let through this particular port number (and if they 
do, do they without translating the port number?), hence the potential 
need to scan for open ports.  When connecting to a particular wireless 
telecom operator with my corporate VPN, it won't get through even if I 
set the flag "NAT present", even the flag "use port 80".

Can IKEv2 for v4 help with this issue?  Does IKEv2 for v4 has any 
reputation of going through all sorts of NAT/NAPTs?

If an implementation of IKEv2 for v4 is able to do this, then I'm fully 
supportive of it.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 07 Apr 2005 14:14:04 -0700

> and nothing about IPv6 IKEv2.

IKEv2 is version neutral. I believe the same mechanisms work
for both v4 and v6.

> through all sorts of NATs, 

yes.

> and if using IKEv2 for v4 does not involve 

for what I understand, the same two round trips that IKEv2 takes
always. somebody correct me if I am wrong.

> reputation of going through all sorts of NAT/NAPTs?

atleast IKEv1 seems to work with most NATs. IKEv2 should work too.
but in general, this is a very difficult question to answer. I
believe not all NATs behave in the same way. we have a WG in the
IETF, BEHAVE, which is trying to figure what is a standard behavior
for NATs. :) http://www.ietf.org/html.charters/behave-charter.html

> If an implementation of IKEv2 for v4 is able to do this, then I'm fully 

draft-wakikawa explains running IKEv2 between MN/MR and HA when
the MN/MR are on a v4 only access network. the MN uses its v4CoA
as the source address in the IKE negotiation. the negotiation is
done with the v4 address of the HA. the final security associations
are created between v6 HoA and v6 address of the HA.

Vijay