Re: [MEXT] Review of draft draft-patil-mext-mip6issueswithipsec-01

[[e-mail] (Arnaud Ebalard)]

Hi,

<[e-mail]> writes:

>>You should introduce the SDOs here i.e. have "some SDOs (XXX, YYY,
>>...). They are *never* cited in the whole document. The issues common
>>and specific to each of those about IPsec/IKE should be summarized in
>>the document.
>
> MIP6 itself has been specified as a solution by NWG in WiMAX forum,
> 3GPP2 and DSMIP6 has been specified by 3GPP in Rel 8. Will mention in
> the next rev of the I-D.

Thanks. 


>>> 4.  Problem Statement
>>>
>>>    Mobile IPv6 is encumbered by its reliance on IPsec [RFC4301] from an
>>>    implementation and deployment perspective.  As a protocol solution
>>>    for host based mobility, MIP6 can be simpler without the IPsec
>>>    baggage.  The issues with IPsec are even more exacerbated in the case
>>>    of dual-stack MIP6 [RFC5555].
>>
>>Sorry, but the design decisions taken for DSMIPv6 make it the way it
>>is. You cannot blame IPsec/IKE for IPv4/NAT issues. The problem with
>>DS-MIPv6 is that it does not provide IPv6 connectivity for the MN that
>>could be used transparently by the stack (Teredo does that). When the
>>protocol has been designed, it has been decided to open the door to
>>IPv4, which let the NAT issue enter. Due to that decision, the
>>difficulties of IPv4/NAT have also impacted the use of DSMIPv6 with
>>IPsec/IKE.
>
> Agree. But the point is because of the security architecture of MIP6
> is based on IPsec, the issues with IPv4/NAT are inherited by DSMIP6
> and as a result the protocol becomes much more complex... At least
> from implementations perspective.

Trying to provide a mobility solution that support all combinations of
IPv4/IPv6 CoA w/ IPv4/IPv6 HoA in environments which include NAT is the
main explanation. That been said, IPsec/IKE are not known to be very NAT
friendly. Said otherwise, NAT prevents IPsec/IKE deployment. It depends
on the way you see it. I think MIPv6 (and IPv6) designers made the
hypothesis IPsec and IKE were usable on IPv6 networks. It was kind of
decided to take a new start w/o NAT i.e. w/ the hypothesis of flat and
E2E-friendly networks. Accepting regressions in our security solutions
to keep coping w/ NAT is IMHO a bad path to follow.


>>>    IPsec is unable to provide security protection for MIP6 in a
>>>    transparent way, and numerous interactions between the host's
>>>    security subsystems and the MIP6 application are needed in the course
>>>    of the regular operation of the MIP6 application.
>>
>>For common scenario, MIGRATE/KMADDRESS solution is sufficient. This
>>requires small changes to the IPsec stack, the IKE daemon and the MIPv6
>>module. After 3776, it is my feeling that MEXT documents have slowly
>>shifted towards tighter relationships between the MIPv6 module and the
>>IKE (address assignment) module to the point that it would be difficult
>>today to provide all the functionalities pushed so far without having a
>>common MIPv6/IKE module (or at least complex interactions between
>>those).
>
> Agree. And the issue is with the fact that complex interactions are
> needed between the modules. Basically you cannot expect to use the
> existing IPsec/IKEv2 engine on a host to work with your MIP6
> implementation with no changes. You end up having to modify the
> security module to work with (DS)MIP6 module and this is not a task
> for the faint-hearted.

I think we agree. IMHO, supporting suspend (to RAM) for recent laptops
which includes a lot of features and devices is also not a task for the
faint-hearted. Nonetheless, people managed to implement it and make it
work. I think there are thinsg that are far more complex than the
required basic (I don't consider the dynamic address assignment
extension) interactions between the modules. My best arguments are:

 - spec is quite short.
 - implementation exist and work.


>>>    Besides requiring an extensive communications channel between the
>>>    security subsystems and the MIP6 application, those interactions
>>>    often also require modification of the MNs security subsystems
>>>    code.
>>
>>Well, I expect all possible L3 solutions to require changes to the
>>security subsystems to support MIPv6 needs but I'd like to be proven
>>wrong.
>
> Take a look at the TLS based security architecture framework solution
> proposed in I-D:  draft-korhonen-mext-mip6-altsec-01.txt

I read the draft. If I had to summarize the protocol the protocol I
would say the HAC provides the same function as a KDC in Kerberos
domains, granting HTTP tickets using TLS. Then, is looks 
like a kerberos-based relying on TLS (or even DTLS) for MIPv6 is IMHO a bad design idea. I
did not resist to take a *quick* look: 

 o there is an additional box in the picture, the HAC

 o "This specification defines a generic packet format, where everything
    is encapsulated inside an UDP."

 o You implement a mapping between TLS1.2 negotiated ciphersuite and ESP
   algs.

 o The only notable difference is that the SPI is prefixed with 4-bit
   PType field leaving 28-bit SPI value, although from the ESP
   processing point of view, the 4-bit PType and 28-bit SPI are handled
   as one "32-bit SPI".
 
 o section 5.2, the LS_RSA_WITH_AES_256_CBC_SHA is wrong, isn't it? It
   should map to AES-256 instead of AES-128.

 o The treatment of MN-CN route optimization is outside the scope of
   the document.

 o In 5.4.2, "The MN or the HA MAY switch between the encryption and
   plain text at any time based on local policies": what if an attacker
   knows the SPI and the sequence number. Can she start sending
   plaintext packets to one or another endpoint just by changing the
   ptype? 

 o You use the IPsec stack to protect traffic using ESP. You use SA for
   that purpose. There is nothing in the document about associated
   Security Policies (SP). Are the ones defined in 3776 reused?
   Can you clarify that point? 

At some point, considering you drop RO, I wonder why not going for one
of the following solutions instead of keeping MIPv6 in the picture: 

 - use of a DTLS-based VPN w/ session resumption
 - use of an IKEv2 MOBIKE-enabled VPN


> We believe that it does not require changes to the security engine on
> the host. It is a solution which uses the APIs and libraries of TLS on
> the host without having to modify them.
> The problem with IPsec/IKEv2 and MIP6 is that we end up having to
> modify the security subsystem to make it work and this is not a
> feasible option in all instances.

One of the problem you have with MIPv6 are the required interactions
with IPsec/IKE, for instance in order to update the SA endpoints. In
draft-korhonen-mext-mip6-altsec-01.txt, you skip this point and do not
explain how the interactions with the IPsec stack are done. Can you
clarify? 


>>>    The situation today is such that the communications channel
>>>    between the IPsec subsystems and the MIP6 application is non
>>>    existent and this is generally true for most of the commercially
>>>    available platforms.
>>
>>The sentence is correct.
>>
>>Well, I won't advocate for other platforms but at least Linux has that
>>now, which proves it is feasible:
>>
>> - Upstream Kernel supports full MIGRATE/KMADDRESS since 2.6.28. Current
>>   is 2.6.30.
>> - racoon (IKEv1) has support for MIGRATE/KMADDRESS for a while now
>> - StrongSwan developers have added support for MIGRATE/KMADDRESS to
>>   Charon, their IKEv2 daemon.
>
> Right... And this is what we have worked with on our implementation as
> well. While we can use these interfaces, I should say that it is still
> not easy and again these are not available on all platforms.
>
>> - patches exist for racoon2
>>
>>I can't say about *BSD platform.
>
> Or for that matter Symbian or Maemo (linux) etc..

Considering current work of Nokia developers in Linux Kernel, I expect
the future brother of the N810 which will run Maemo 5 to include a
post-2.6.28 kernel, which will make it almost directly MIPv6 w/
IPsec/IKE capable.

BTW, you may be interested by what is on http://natisbad.org/N810 + the
armel packages for Debian now available on the repository advertised on
http://natisbad.org/MIPv6. 


>>>    Even if such a channel were to be available, there does not exist a
>>>    standardized protocol over that channel which would enable the MIP6
>>>    application to communicate with the security modules in a non-
>>>    implementation specific way.
>>
>>Well, I already pointed that and even provided follow-up work for
>>MIGRATE/KMADDRESS but this was considered out of scope for the
>>WG. Having that work done in the context of ipsecme WG was not possible
>>either.
>>
>>But thanks for stressing that point.
>
> Right.. We did note work (reference) done by you in this context. But
> it has not really progressed.

I could have kept incrementing the number at the end of the draft every
6 months or so but this is pointless if the chairs consider that the WG
should not work on such interfaces.


>>>    Considering a third party application developer who would like to
>>>    provide a MIP6 application for a particular platform, the need for
>>>    numerous interactions with the IPsec subsystem and the unavailability
>>>    of the standardized communications channel through which such
>>>    interactions could take place is a major obstacle to the
>>>    implementation of the mobility protocol.  Without such a
>>>    communication channel being available it is not possible to implement
>>>    a MIP6 application as a third party developer.
>>
>>3 main possible solutions:
>>
>>  - standardize the interface
>>  - make MIPv6 module and IKEv2 module a common module (as
>>    progressively expected by MEXT documents published after 3775)
>>  - give up on the use of IPsec/IKE
>
> Yes... The last option is what we are recommending. The others do not
> seem to be easily surmountable.

I think we just disagree on that part ;-) I prefer the first option.


>>>    The problem in a nutshell for MIP6 is the dependence on IPsec and
>>>    IKEv2 for successful operation.
>>
>>I respectfully disagree, not with the various points above, but with the
>>way you interpret them. Vendors implement features in their products
>>based on business case and possibly the availability of a standard. If
>>open source product already have the feature, I think may indicate the
>>issue is not the technical feasibility ...
>
> Having worked on this implementation, I am not arguing that it cannot
> be done. All I am saying is that it is a real pain to implement it and
> get it working. Additionally while it is possible to do this on open
> source where you have control of all the modules, it is not
> necessarily the case on all platforms. For example you would not be
> able to modify the IPsec/IKEv2 modules on Symbian if you were building
> the MIP6 module. Only Symbian could do that. And the same goes for
> many other platforms as well.
>
>>
>>From a discussion I had with some MS engineers after they unleashed the
>>details on Vista's IPv6 stack, asking them for the reasons why it had no
>>MIPv6 support: no business case and no standard interface to secure
>>it.
>
> No business case from the perspective of MS... Maybe. But I am not
> sure I understand what you meant by "no standard interface to secure
> it".

[Probably] Due to their history, MS now consider the security aspects of
a protocol before putting it in their system. It's nice to have a
feature. It's a pain if it can be subverted with no way to prevent that.


>>3775 and 4877 provide a *generic* solution for the Internet environment,
>>i.e. common platforms and systems. As you write, "[IPsec as a default
>>feature] is true in many host implementations today". If specific
>>systems have specific needs which do not fit with a generic solution,
>>then they need a specific solution. If they are so specific, they may
>>simply not be in the scope of MIPv6 generic solution.
>
> Let me give you an example.. A mobile phone (not the smartphone types
> lets say) does not need IPsec/IKEv2. However it does not need mobility
> support on networks which would provide mobility via an HA. So the
> point is mobility may be a requirement in certain cases, whereas
> IPsec/IKEv2 is not.

I wonder if in two years Nokia (or other phone vendors) will have
non-smartphone phones. It's like looking today for a phone without a
camera.


> IPsec in hosts is used primarily (and probably only) by VPN
> applications. Is there any other protocol on a host which requires
> IPsec? So why is MIP6 having to rely on IPsec and IKEv2.

Because MIPv6 is not a L4 protocol but an extension of IPv6. 


> The design goals in the late 90s were based on some principles which
> are not very practical today.

You are thinking about "Client/Server" model forced by NAT I presume ? ;-)


>>>         MIP4 signaling is integrated into the protocol itself.  MIP4 has
>>>         been successfully deployed on a large scale in several networks.
>>
>>Can you describe the assumptions about those network? Do they come with
>>link layer security for instance?
>
> Yes. They do have security at the lower layers.
>
>>Can a user of those networks move to
>>the Starbuck at the corner and use the wifi there without the need to
>>care about how its data are protected on that foreign network?
>
> They could. Depends on the type of data and how concerned they are
> about protecting it (i.e level of paranoia).
>
>>
>>RFC 3775 Introduction starts with: "This document specifies a protocol
>>which allows nodes to remain reachable while moving around in the IPv6
>>Internet"
>>
>>>    (2)  IPsec use in most hosts is generally for the purpose of VPN
>>>         connectivity to enterprises.  It has not evolved into a generic
>>>         security protocol that can be used by Mobile IPv6 easily.  While
>>>         RFC4877 does specify the details which enable only the MIP6
>>>         signaling to be encapsulated with IPsec, the general method of
>>>         IPsec usage has been such that all traffic between a host and
>>>         the IPsec gateway is carried via the tunnel.  Selective
>>>         application of IPsec to protocols is not the norm.  Use of IPsec
>>>         with Mobile IPv6 requires configuration which in many cases is
>>>         not easily done because of reasons such as enterprise
>>>         environments preventing changes to IPsec policies or other.
>>>    (3)  A MIP6 home agent is one end of the IPsec SA in a many-to-one
>>>         relationship.  A MIP6 HA may support a very large number of
>>>         mobile nodes which could be in the hundreds of thousands to
>>>         millions.  The ability to terminate a large number of IPsec SAs
>>>         (millions) requires signifiant hardware and platform capability.
>>>         The cost issues of such an HA are detrimental and hence act as a
>>>         barrier to deployment.
>>
>>Can some vendor comment on that. Do we agree that the amount of traffic
>>is not the issue but the initial IKE negotiation and the number of SA
>>might be?
>
> The number of messages exchanged to setup the IPsec SA is an
> issue. Especially when you compare it with the registration process
> required for MIP4. So if you compare the number of steps for
> registration of an MN for MIP6 vs MIP4, you would see the difference.

Can you compare the amount of traffic exchanged between a MN and a HA
using IKEv2 to setup the SA with the traffic exchanged in an alternate
solution, say draft-korhonen-mext-mip6-altsec-01.txt?


>>>    (4)  The implementation complexity of Mobile IPv6 is greatly
>>>         increased because of the interaction with IPsec and IKEv2.  A
>>>         standalone MIP6 protocol is easier to implement and deploy (such
>>>         as MIP4 [RFC3344]). The complexity of the protocol
>>>         implementation is even more so in the case of Dual stack MIP6
>>>         [RFC5555].
>>
>>MIPv6 and MIPv4 do not have equivalent feature security-wise. MIPv6 is
>>certainly more complex on that aspect than MIPv4 but it allows
>>more.
>
> More is not necessarily good :) (Kitchen sink protocol design)
>
>> Moreover, it builds (even if some bits may be missing
>>interface-wise) on existing and mature protocol (not speaking about
>>IKEv2 yet ;-) ) which prevents reinventing the wheel.
>
> Well show me another protocol on the host which relies on the reuse of
> an existing and mature protocol like IPsec.

All the TCP and UDP based protocols my VPN carry without the need to
worry about the environment in which I am at a given moment.


>>>    (5)  IPsec and IKEv2 are not implemented or available by default in
>>>         every IPv6 or dual stack host.
>>
>>Can you list some (2 or 3) systems that are of common use today and that
>>do not have that?
>
> Proprietary OS' come to mind. Devices with these types of OS' are
> fairly common.

Can you cite vendors and devices?


>>>         Mobile IPv6 support on such devices is not an option.  Many
>>>         low-end cellular hosts have IP stacks.  The need for IPsec and
>>>         IKEv2 in these devices is not important whereas mobility
>>>         support is needed in many cases.
>>
>>I may be wrong but the way I see it is that current trend if for
>>cellular devices to come with complete systems today: what does the
>>iPhone runs? Nokia is currently shifting towards Linux based solutions
>>(ofono, maemo, ...)? Many phones runs Windows Mobile too, ...
>>
>>If you consider the previous devices and most of the laptop (99% of
>>the latter running Mac OS X, Linux or Windows), I think you have the
>>initial targets MIPv6 is trying to provide mobility for. Or am I missing
>>your point?
>
> Well.. Nokia devices based on Maemo and Symbian do include IPsec
> support. But for lower end devices which are primarily intended for
> voice service and some data, there is no IPsec even though there is an
> IP stack. Additionally I dont know about many other devices which are
> becoming capable of connecting to the Internet but do not need an
> IPsec stack.

Is that what you meant in the last sentence?


>>>         A simpler security protocol than the use of IPsec/IKEv2 would make
>>>         MIP6 much more attractive to implement and deploy.
>>
>>Those sepecific devices may need a specific solution. I agree on that.
>>
>>>    (6)  [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile
>>>         IPv6 essentially results in a variant of IPsec which is specific
>>>         to Mobile IP.
>>
>>No. IPsec stack and IKE daemon may already have support for MOBIKE which
>>does exactly what we need. The only difference is that the signaling
>>goes through the IKE channel. With MIPv6, signaling is MIPv6 one
>>(BU/BA). In all cases, extending the IPsec stack to support MIPv6 is
>>light. Same for IKE.
>
> I think this where I would disagree. At least from our experience of
> doing a DSMIP6 implementation, the challenges are primarily in the
> interactions between the mobility module and the IPsec/IKEv2
> modules. YMMV.

I won't argue for DSMIPv6.


>>>         Hence this results in added complexity to implementations.
>>
>>No. Compare the small required extensions (MIGRATE/KMADRESS is short to
>>read) with what it would cost to provide the same amount of features
>>(protecting signaling and possibly data) but by designing and
>>implementing a specific protocol in the MIPv6 module.
>>
>
> Making changes to the IPsec or IKEv2 modules may not always be an
> option. Especially if you have no control of those modules on a
> host. You would then have to rely on these interfaces being
> standardized and implemented on all hosts for the mobility module to
> rely on.
>
>>IMHO, a simple extension cost less than a complete new design. And
>>considering you are speaking about a security solution, designing from
>>ground a new security solution for your own need is starting looking for
>>trouble, all the more if you are trying to provide a L3 security
>>solution, i.e. trying to compete with IPsec/IKE.
>
> I think we can do simpler security solution than IPsec/IKEv2 which
> would simplify the implementation vastly while preserving the security
> aspects of the MN-HA communications.

At the moment, draft-korhonen-mext-mip6-altsec-01 relies on TLS, IPsec,
HTTP, BNF, RFC3948, ... and an additional box.


>>>    (7)  Mobile IPv6 needs to be capable of being deployed in situations
>>>         where alternative security mechanisms are already well-
>>>         understood by the network administration.  It should be possible
>>>         to enable Mobile IPv6 to work in situations where alternative
>>>         security mechanisms already supply the necessary authentication
>>>         and privacy.
>>
>>Agree.
>>
>>>    (8)  IPsec has been successfully applied to VPN and other
>>>         infrastructure operations, but less so for general end-to-end
>>>         applications.  Thus, the granularity for selectors was
>>>         originally not at all sufficient for Mobile IPv6.
>>
>>Yes. The use of new IPsec architecture and IKEv2 in 4877 solved that
>>issue.
>
> True.
>
>>
>>>    (9)  The way that the IPsec code sits in the usual kernel, and the
>>>         access mechanisms for the SA database, are not very convenient
>>>         for use by straightforward implementations of Mobile IPv6.
>>>         Unusual calling sequences and parameter passing seems to be
>>>         required on many platforms.
>>
>>Yes. Standardizing or at least providing some guidance on that would be
>>helpful.
>
> A tall order IMO.

I am not the one you need to convince ;-)


>>>    The solution to this issue could be an out-of-band communication
>>>    channel between the MIP6 application and the key management daemon
>>>    through which the MIP6 application could request the establishment of
>>>    the appropriate IPsec SA from the key management daemon without
>>>    having to install the appropriate SPD entries and generate the BU
>>>    message.
>>
>>yes. Or as it appears to be the underlying assumption a merged MIPv6/IKE
>>module (I don't advocate for that).
>
> A merged MIP6/IKE module is not a feasible option. Given that IKE is
> used as a means to setup an IPsec SA for VPN purposes only, I dont see
> the case for a MIP6 capable IKE module.

Think RO. IMHO, if you consider MIPv6 and remove the RO, you may obtain
something that can easily replaced by a common VPN software w/ MOBIKE
support. 


>>> 6.4.  Registering the MN's FQDN in DNS
>>>
>>>    [RFC4877] allows the HA to register the MN's FQDN in the DNS.  In
>>>    this case the MN must provide the FQDN in the IDi payload in the
>>>    IKE_AUTH step of the IKEv2 exchange.  Consequently, there must be
>>>    some interface between the key management daemon and the MIP6
>>>    application on the HA side through which the FQDN could be made
>>>    available to the MIP6 application so that it can register the FQDN in
>>>    DNS.
>>
>>Can you point a specific section of RFC 4877. I fail to find where this
>>feature is discussed.
>
> I hope Domagoj can answer this.

I'll wait for his answer.


>>> 6.5.  Providing the Home Network Prefix to the MIP6 application
>>>
>>>    When the key management daemon on the MN side obtains the home
>>>    network prefix information from the HA, it needs to relay this
>>>    information to the MIP6 application.  This again requires a
>>>    communication channel between the key management daemon and the MIP6
>>>    application.
>>
>>yes.
>>
>>> 6.6.  SPD Entry for the HoA on the MN side
>>>
>>>    Once the MIP6 application on the MN obtains the HoA (either assigned
>>>    via the CONF IKEv2 payload [RFC4877] or autoconfigured from the
>>>    MIP6_HOME_PREFIX [RFC5026]), the appropriate SPD entries need to be
>>>    created in the SPD.  Some key management daemons may require that
>>>    they have full control of the SPD.  In such cases the MIP6
>>>    application should not create the SPD entries by itself as this might
>>>    confuse the MIP6 daemon and cause inconsistent state. Instead, the
>>>    MIP6 application would need to instruct the key management daemon to
>>>    create the appropriate SPD entries.
>>
>>StrongSwan developers hit that issue when implementing
>>MIGRATE/KMADDRESS because UMIP (the Mobile IPv6 daemon for Linux)
>>handles all the policies. It just let the IKE daemon perform the SA nego
>>for those policies. I think this is handled via the installpolicy=no in
>>the configuration described on the following page:
>>
>>   http://wiki.strongswan.org/wiki/strongswan/MobileNodeSetup
>
> Right.. Our implementation experience has been with Strongswan as well.

The feature is available upstream now.


>>> 6.8.  The K bit
>>>
>>>    The K bit [RFC3775] requires an interface between the IPsec subsystem
>>>    and the MIP6 application that is not available today, at least not in
>>>    a standardized form.  Such an interface that would enable the support
>>>    for the K bit has been proposed before and additional information how
>>>    it might look like is available in [I-D.sugimoto-mip6-pfkey-migrate]
>>>    and [I-D.ebalard-mext-pfkey-enhanced-migrate].
>>
>>the latter is a follow-up of the former. Implementation feedback
>>provided by the implementation of the former showed that
>>SADB_X_EXT_PACKET mechanism had drawbacks. Hence the extension to use
>>KMADDRESS.
>>
>>[I-D.ebalard-mext-pfkey-enhanced-migrate] is currently available as a
>>draft and implemented. I had discussion with the chairs to go further in
>>the context of MEXT but the WG is not supposed to work on that kind of
>>item.
>
> Bummer.. And hence essentially no real solution being available.

You can help me push things forward ;-)


>>>  Standardizing such communication channel and having it
>>>    available in a commercial OS implementations is not a realistic
>>>    proposal in any practical time frame.
>>
>>Please, site names of vendors and OS, not in the draft but on the
>>list. This is looks like a vendor issue more than anything else. I don't
>>like the logic but if you have a business case for them then previous
>>issue vanishes.
>>
>>>  On the technical side, this is
>>>    due to the fact that the IPsec is usually provided as part of the OS
>>>    kernel and it is always difficult to convince the OS vendor to change
>>>    the kernel and in particular the security related subsystems.  The
>>>    other difficulty is that the key management is usually provided as
>>>    the user space service and as such there are multiple key management
>>>    daemons available.  Convincing vendors of various key management
>>>    daemons to provide a unified or standardized communication channel
>>>    for the MIP6 application might prove equally difficult and is not a
>>>    realistic option either.
>>
>>You don't have to convince vendors. If the protocol is available
>>(documented) and the feature is worth implementing for their clients, I
>>don't see why they would refuse if other vendors would agree.
>
> I think vendors will shy away from (DS)MIP6 implementation after they
> see the complexity or have made some attempts to experiment with
> it. Making the protocol easier to implement at least would spur
> further implementations and hopefully gain some traction.

We do not need to change the whole protocol for that purpose. Mainly
specify the missing parts ...


>>>  Besides the technical reasons, there are
>>>    also other non-technical reasons of business or political nature why
>>>    such proposals would be unrealistic.
>>
>>Can you extend that sentence into a paragraph. It looks promising ;-)
>
> Will try in the next rev... But I dont know if we want to be
> sidetracked into a discussion of why MIP6 is not implented in more
> platforms today.

I am Looking forward to read it.


>>>    In order to make the Mobile IPv6 protocol a solution that is easy to
>>>    implement and available in even low-end devices, it is necessary to
>>>    simplify the protocol.  The design or the security architecture for
>>>    MIP6 needs to be revisited and a solution that simplifies the
>>>    implementability of the protocol considered.  The implementation
>>>    experience shows that a working solution of Mobile IPv6 is possible
>>>    to build.  However it is not easily done.
>>
>>
>>> 8.  Security Considerations
>>>
>>>    This I-D discusses the security architecture of Mobile IPv6 which is
>>>    based on IPsec.  The dependency on IPsec for security of MIP6
>>>    signaling is a detriment to the protocol implementation and
>>>    deployment.  Hence the current security architecture needs to be
>>>    reconsidered.
>>>
>>>    The experience gained over the last few years indicates that IPsec
>>>    cannot necessarily be used as a generic solution for security.
>>
>>IPsec cannot be used to protect all protocols. Hence the specification
>>of SEND for instance. But I think MIPv6 is among the few protocols which
>>have made effort to build their security on IPsec/IKE without relying
>>only on a simple sentence somewhere in the document stating "for
>>security needs, IPsec should be use". I would agree that more work is
>>needed on some aspects (interfaces) even if the WG is more interested by
>>pushing additional features.
>>
>>If the security work on IPsec/IKE integration with MIPv6 had been
>>completed before the extension of the protocol (DSMIPv6, ...), this
>>may have prevented such issues.
>>
>>I agree that some of the features described in companion documents of
>>MIPv6 have been described at a too high level and cannot be implemented
>>easily.
>
> Thank you. I think you will realize the complexities of the
> implementation when you go through an exercise of doing so.

I won't. I just don't support DSMIPv6. Reread my email address more
carefully ;-) 


>>>    Authors would also like to recognize Satyabrata Sahu, NK Garg,
>>>    Sandeep Minocha and Harsh Verma for working on the implementation.
>>
>>What about discussing the specific technical details of the problems
>>they found during the implementation on the list and try and address
>>them one by one. Can I also ask what they implemented precisely and for
>>which specific platform? I would understand if that cannot be discussed
>>publicly, obviously.
>
> We can discuss this offline. But I can say that the implementation of
> DSMIP6 was done on a RHEL version of Linux.

let's do that part offline.

Cheers,

a+