Subject: [MEXT] situation with the -whyauthdataoption document

From: Jari Arkko <[email-masked]>
Date: Mon, 08 Sep 2008 13:38:05 +0300

WG, Basavaraj, Gopal,

I wanted to let everyone know where we are with this document. It was in 
the IESG review a week ago. There are a few details to change here and 
there, but the main issue is in Pasi Eronen's Discuss. It is copied 
below. I do agree with Pasi, and I'd like the authors to revise the 
document accordingly. After this revision, it will be a much better 
document -- particularly because also adds important arguments.

> First of all, I should say that after working on the DSMIPv6 
> document, I'm rather sympathetic to arguments that perhaps using 
> IPsec for Mobile IPv6 wasn't such a great idea in hindsight, and 
> the authentication option can be valuable in some deployments.
>
> Nevertheless, I think the document's discussion of pros and cons of
> authentication option and IPsec is a bit too 3GPP2-centric, and 
> implicitly assumes some functionality of 3GPP2 networks that may 
> or may not be present in other networks.
>
> To make the document more useful for a reader trying to understand the
> pros and cons of authentication in other environments than 3GPP2, IMHO
> it would be useful to make these assumptions more explicit.  Here's an
> attempt (proposing text for Section 7) to clarify what I mean:
>
> 3. In 3GPP2 networks, link-layer security mechanisms, ingress
>    filtering at the PDSN, and various network domain security
>    mechanisms largely ensure that reverse tunneled packets received by
>    the HA don't have spoofed source addresses, and their contents have
>    not been modified.  This means the HA can determine which MN sent
>    the packet simply by verifying the outer source IP address matches
>    the currently registered care-of address. Authentication of 
>    payload packets can be necessary for e.g.
>
>    - Authenticating other signalling messages than BU/BAck between 
>      the MN and HA, such as ICMPv6, MLD, and DHCPv6.
>    - Enforcing access control to the network behind the HA.
>    - Accounting or other flow-specific processing performed by the HA.
>
>    This means the authentication option is of limited applicability in
>    environments where the HA can received reverse tunneled packets
>    with spoofed source IP addresses and/or modified contents.
>
> 4. As described in RFC 4285, the authentication option assumes that
>    the MN-AAA shared key and security association (SA) are created by
>    out-of-band mechanisms.  These mechanisms are specific to
>    particular deployment environments. IKEv2, on the other hand,
>    supports a wide range of authentication mechanisms, such as
>    certificates and EAP methods, and is independent of the access
>    network technology being used.  However, it would be possible to
>    specify a similar authentication and key management protocol for
>    the authentication option in the future.
>
> 5. RFC 4285 does not specify a mechanism for creating the MN-HA 
>    shared key and SA from the MN-AAA SA (unlike similar Mobile IPv4
>    mechanisms defined in [RFC3957]), and thus rely on deployment
>    specific mechanisms not standardized in IETF.
>
> 6. Sending the long-term user identity (NAI) in clear raises privacy
>    concerns. These concerns are addressed by access network and network
>    domain security mechanisms in 3GPP2 networks, but do limit the
>    applicability in networks where sniffing other users' traffic
>    is possible.
>
> 7. The authentication option does not support negotiation of
>    cryptographic algorithms.
>
> 8. The replay protection mechanisms in RFC 4285 rely on timestamps,
>    and thus requires reasonably synchronized clocks (by default, ±
>    7 seconds). This assumes the MN implements, and is configured to
>    use, some mechanism for synchronizing its clock.
>
> Any thoughts on these, and/or proposals on how to better write this
> text?
>
> (Note that these concerns are largely addressed by other mechanisms
> than IPsec in 3GPP2 networks, so the conclusions of the document
> stay valid.)
>
> Another concern is that much of the text in Sections 2/3/4 is written
> in way that was true when RFC 4285 was done, but isn't true anymore.
> Just adding "BTW, IKEv2 and RFC 4877 means the previous text is now
> incorrect" doesn't really make it good -- the incorrect text is still
> written in present/future tense, giving advice for the future. Changing
> it to past tense would perhaps make it clearer when it's just describing
> the history behind RFC 4285. 
>
> Somewhat surprisingly for a document defending RFC 4285, the document
> also doesn't mention what's IMHO the *main* advantage of RFC 4285
> over IPsec: implementation complexity. Especially with new MIPv6 
> features like DSMIPv6, the interface between IPsec stack and MIPv6
> stack is getting complex, and the IPsec stack needs more MIPv6-specific
> functionality (so you can't necessarily use just any off-the-shelf IPsec 
> stack).
>   

Jari

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 08 Sep 2008 14:45:53 +0200

Hi,

Jari Arkko <[email-masked]> writes:

>> IPsec for Mobile IPv6 wasn't such a great idea in hindsight

I am probably a bit biased on the topic but I am sure the following
arguments are valid.

IPsec works fine in IPv6 environments. It also works fine in MIPv6
environments, even with dynamic keying when using the appropriate
interface between MIPv6 and IPsec/IKE.

NAT and IPv4 have always been problematic for IPsec/IKE. MIPv6 has
always been an IPv6 mechanism: we should not blame the choice of IPsec
now that IPv4 and NAT are on the table with the design of DSMIPv6.

>> , and the authentication option can be valuable in some deployments. 

in *some* deployments, maybe.

But in IPv6 environments, i.e. initial the target of MIPv6, IPsec is
available and the required extensions (interface between IPsec/IKE and
MIPv6) can be very limited in size.

>> [snip]
>> over IPsec: implementation complexity.

All IPv6 stacks must support IPsec. For a MIPv6 implementation based on
those stacks, adding the required bits to support interactions with
IPsec is not that complex (less than 600 lines in Linux Kernel for
current MIGRATE implementation for both XFRM and PF_KEY, for instance).

Then, adding the missing bits for IKE requires some care but it is not
so difficult. If you want the values for userland counterparts (MIPv6
daemon and IKE daemon), I can check.

Out of curisoity, can someone provide some feedback on RFC 4285
implementation?

>>  Especially with new MIPv6 features like DSMIPv6 the interface
>> between IPsec stack and MIPv6 stack is getting complex

If normalized at some point, it will probably be ;-)

>> and the IPsec stack needs more MIPv6-specific functionality (so you
>> can't necessarily use just any off-the-shelf IPsec stack

If "off-the-shelf IPsec stack" means only RFC430*-compliant ones, that's
true. Now, you can expect some common IPsec stack to provide the
required MIPv6-specific functionality if those are normalized
(i.e. IETF reference documents produced by a WG).

But we cannot blame the IPsec stacks not to implement features that the
IETF is not willing to work on / push.

Cheers,

a+

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 08 Sep 2008 09:33:04 -0500

Hi Jari/WG chairs,

I will revise the I-D and respond to Pasi's comments this week.

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 8 Sep 2008 16:34:42 -0700

I concur with many points Arnaud raises below.  I do agree that the
draft needs to be updated with the correct current status of things with
IKEv2/IPsec.  But, I don't think it makes sense to justify the use of
RFC4285 on the basis of implementation complexities associated with
using IPsec with MIP6, especially given that the complexity has to do
with NATs rather than MIP6. 

- Vidya

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Arnaud Ebalard
> Sent: Monday, September 08, 2008 5:46 AM
> To: Jari Arkko
> Cc: [email-masked]; Pasi 
> Eronen; [email-masked]
> Subject: Re: [MEXT] situation with the -whyauthdataoption document
> 
> Hi,
> 
> > I wanted to let everyone know where we are with this 
> document. It was 
> > in the IESG review a week ago. There are a few details to 
> change here 
> > and there, but the main issue is in Pasi Eronen's Discuss. It is 
> > copied below. I do agree with Pasi, and I'd like the 
> authors to revise 
> > the document accordingly. After this revision, it will be a much 
> > better document -- particularly because also adds important 
> arguments.
> >
> I am probably a bit biased on the topic but I am sure the 
> following arguments are valid.
> 
> IPsec works fine in IPv6 environments. It also works fine in 
> MIPv6 environments, even with dynamic keying when using the 
> appropriate interface between MIPv6 and IPsec/IKE.
> 
> NAT and IPv4 have always been problematic for IPsec/IKE. 
> MIPv6 has always been an IPv6 mechanism: we should not blame 
> the choice of IPsec now that IPv4 and NAT are on the table 
> with the design of DSMIPv6.
> 
> But in IPv6 environments, i.e. initial the target of MIPv6, 
> IPsec is available and the required extensions (interface 
> between IPsec/IKE and
> All IPv6 stacks must support IPsec. For a MIPv6 
> implementation based on those stacks, adding the required 
> bits to support interactions with IPsec is not that complex 
> (less than 600 lines in Linux Kernel for current MIGRATE 
> implementation for both XFRM and PF_KEY, for instance).
> 
> Then, adding the missing bits for IKE requires some care but 
> it is not so difficult. If you want the values for userland 
> counterparts (MIPv6 daemon and IKE daemon), I can check.
> 
> Out of curisoity, can someone provide some feedback on RFC 
> 4285 implementation?
> 
> If "off-the-shelf IPsec stack" means only RFC430*-compliant 
> ones, that's true. Now, you can expect some common IPsec 
> stack to provide the required MIPv6-specific functionality if 
> those are normalized (i.e. IETF reference documents produced by a WG).
> 
> But we cannot blame the IPsec stacks not to implement 
> features that the IETF is not willing to work on / push.
> 
> Cheers,
> 
> a+

---

From: <[email-masked]>
Date: Tue, 9 Sep 2008 14:46:28 +0300

> MIPv6) can be very limited in size.

If by "MIPv6" you mean RFC 3775 only, I agree that the interface was
back then quite clean, and limited in size. If you include all the
extensions developed since RFC 3775, things get more complex.

Best regards,
Pasi

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 10 Sep 2008 09:28:53 -0500

I also would like to comment on the justification of the need to use
Auth Protocol (RFC4285) based on the argument that MIP6 IPsec based
solution is becoming very complex.

I agree on the fact that any IPv6 mobility protocol (Client based or
Network based) needs to sincerely address the transitional period of
IPv4 transport/addressing while evolving to a full IPv6 deployment. I
also may add that this transitional period could take a long time.
However, trying to address every home-made deployment where a NAT MAY
exist in any place in the network is to some extent an exaggeration, the
least to be said. Also, IMO, that does not help in speeding IPv6
deployment nor shortening the transitional period.

For sure when all kind of NAT possibilities needs to be considered then,
you will have a complex IPsec based solution. But, many deployments do
not need to have that complexity! IMO, the best approach is to define
the respected standard which addresses the major deployments where a NAT
is not present and, after or in parallel, the solution which addresses
the presence of NAT wherever it is needed or any where in the network is
developed. This way we can have a more accurate assessment of the
complexity of the IPsec base MIP6 protocol before making a 180 degrees
turn and start contradicting what has been said about Auth protocol and
RFC4285.

Additionally, since probably all of the supporting mechanisms for a full
and dynamic deployment of IPsec based MIP6 solution has been identified
over the last few years, it will be a very good to have a quick exercise
on what is needed to bring Auth protocol solution to equal footing and
probably then compare its complexity too!

My 2 cents.

Regards,
Ahmad

> Behalf Of Narayanan, Vidya
> Sent: Monday, September 08, 2008 6:35 PM
> To: Arnaud Ebalard; Jari Arkko
> I concur with many points Arnaud raises below.  I do agree 
> that the draft needs to be updated with the correct current 
> status of things with IKEv2/IPsec.  But, I don't think it 
> makes sense to justify the use of
> RFC4285 on the basis of implementation complexities 
> associated with using IPsec with MIP6, especially given that 
> the complexity has to do with NATs rather than MIP6. 
> 
> - Vidya
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Arnaud Ebalard
> > Cc: [email-masked]; Pasi Eronen; 
> > [email-masked]
> > MIPv6 has always been an IPv6 mechanism: we should not blame the 
> > choice of IPsec now that IPv4 and NAT are on the table with 
> the design 
> > of DSMIPv6.
> > 
> IPsec is 
> implementation based 
> > on those stacks, adding the required bits to support 
> interactions with 
> > If "off-the-shelf IPsec stack" means only RFC430*-compliant ones, 
> > that's true. Now, you can expect some common IPsec stack to provide 
> > the required MIPv6-specific functionality if those are normalized 
> > But we cannot blame the IPsec stacks not to implement features that 
> > the IETF is not willing to work on / push.
> > 
> > Cheers,
> > 
> > a+

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 10 Sep 2008 17:34:32 +0200

Hi,

"Ahmad Muhanna" <[email-masked]> writes:

> IPv4 transport/addressing while evolving to a full IPv6 deployment.

This is a possibility. Another one is to expect IPv6 transition
mechanisms to provide access to the IPv6 internet from an IPv4 public
address (6to4 for instance), from behind a NAT (Teredo for instance),
...

I fail to see why IPv4/NAT issues are or should become a MIPv6 issue.

> I also may add that this transitional period could take a long time.
> exist in any place in the network is to some extent an exaggeration,
> the least to be said. Also, IMO, that does not help in speeding IPv6 

+1

> For sure when all kind of NAT possibilities needs to be considered
> then, you will have a complex IPsec based solution. But, many
> deployments do not need to have that complexity! IMO, the best
> approach is to define the respected standard which addresses the major
> deployments where a NAT is not present and, after or in parallel, the
> solution which addresses the presence of NAT wherever it is needed or
> any where in the network is developed.

At the moment, when I am stuck in an IPv4 network, my teredo client
manages to configure an address which my MIPv6 daemon, my IPsec stack
and my IKE daemon are happy to use *in a transparent fashion*.

Note that I am not advocating for Teredo as a generic solution here but
it has the following advantages:

- unmodified MIPv6
- unmodified IKE
- unmodified IPsec
- Smarter than anything else for bypassing NAT

Note that I am fully aware of Teredo's drawback (MTU, SPoF, ...).

> This way we can have a more accurate assessment of the complexity of
> the IPsec base MIP6 protocol before making a 180 degrees turn and
> start contradicting what has been said about Auth protocol and RFC4285.

+1

> over the last few years,

'identified' is the correct word, i.e. there are many things on the
table but connecting the dots between those is IMHO not done.

> it will be a very good to have a quick exercise on what is needed to
> bring Auth protocol solution to equal footing and probably then
> compare its complexity too!

I agree.

Cheers,

a+