PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE
draft-ebalard-mext-pfkey-enhanced-migrate-01

I have reviewed this draft. I would like to move it to forward, but there are a few technical issues and a number of editorial problems. Please correct the editorial problems and respond on the technical issues. Also, Julien, would it be possible to get some IPsec experts to review this as well?

Technical:

> Mobile IPv6 may need to make an access to the SPD not only for
> updating an endpoint address but also for deleting/inserting a
> specific SPD entry.  When the MN performs Foreign-to-Home movement,
> IPsec SA established between the MN and HA to protect data traffic
> should be deleted, and associated SPD entries should have no effect
> anymore.  On the other hand, when the MN performs Home-to-Foreign
> movement, those IPsec SP should be restored.  Hence security policy
> entries that are associated with tunnel mode SA may dynamically be
> added/removed (enabled/disabled) in along with MN's movements.  As a
> side note for such a scenario, Home Link detection mechanism becomes
> critical security-wise [hld-sec]

Its not clear to me why this disabling is required. Can you elaborate? It seems that since the security policy dictates that communication with the home agent needs to be secured, I'll note that the de-registration BU still needs to be protected. And after that, if there is no communication with the home agent, what problem is solved by removing the SA/SP?

Also, I'm not too happy about including references to major new pieces of needed mechanisms in other drafts, when those drafts are not in IETF process already.

>    o  Key manager address information               
>        *  source address                               
>        *  destination address                         
>    o  Selector information:                         
>        *  source address/port                         
>        *  destination address/port                     
>        *  upper layer protocol (i.e., Mobility Header) 
>        *  direction (inbound/outbound)   

For the tunnel SAs, there will not be a Mobility Header. You say later "For tunnel mode, the endpoint addresses refer to the source and destination IP addresses that appear in the IP header, and those should be provided by the MIGRAT E message." But above you seem to imply that the upper layer protocol is always MH.

>    o  Old SA information:                             
>        *  old source endpoint address                 
>        *  old destination endpoint address             
>        *  IPsec protocol (ESP/AH)                     
>        *  mode (Tunnel/Transport)                     
>    o  New SA information:                             
>        *  new source endpoint address                 
>        *  new destination endpoint address             
>        *  IPsec protocol (ESP/AH)                     
>        *  mode (Tunnel/Transport)                     
>

I do not understand how you identify the SA/SPD entry with this.

> It should be noted that delivery of PF_KEY MIGRATE messages cannot be
> guaranteed, which is common to other PF_KEY messages.  It may be
> possible (even if highly unlikely) that a MIGRATE message be lost.
> In such case, there will be inconsistency between the binding record
> managed by Mobile IPv6 and IPsec database inside the kernel or the
> IKE daemon.  Once a PF_KEY MIGRATE message is lost, it would not be
> possible for the receiver to process some subsequent MIGRATE messages
> properly.  Reinitialization of the Mobile IPv6 stack and IPsec
> databases may be needed for recovery.

I'm not sure I understand why. If the MIGRATE message is copied back to all open PF_KEY sockets, presumably the Mobile IPv6 daemon would also see a copy if the kernel actually received the message. So what is the problem?

Editorial:

>    This document is heavily based on a previous draft [MIGRATE] written
>    by Shinta Sugimoto, Masahide Nakamura and Francis Dupont.  It simply
>    reuses the MIGRATE mechanism defined in the expired document, removes
>    a companion extension (SADB_X_EXT_PACKET) based on implementation
>    feedback (complexity, limitations, ...) and fills the gap by very
>    simple changes to MIGRATE mechanism.  This results in a more simple
>    and consistent mechanism, which also proved to be easier to
>    implement.  This document is expected to serve as a continuation of
>    [MIGRATE] work.  For that reason, the name of the extension has been
>    kept.

This material belongs somewhere else (maybe the introduction or the acknowledgements section) but not in the abstract. Actually, I think the paragraph at the end of Section 1 already is sufficient, so you might be able to remove this text altogether.

>    For the IPsec stack, this allows migrating the endpoint addresses of
>    the IPsec SA (and associated SP).

SP is not defined.

> This memo proposes such an API based
>    on PF_KEY framework both to document the needs and ease
>    interoperability between components which may be provided by
>    different vendors.

Just say "... based on the PF_KEY framework." The rest repeats too much of what was already said in the introduction.

> 5.1.2. Bootstrapping
>
>
>    In the bootstrapping stage of Mobile IPv6

This is somewhat confusing because bootstrapping has a different meaning in the existing mobile IPv6 RFCs; I think you mean the initial registration.

> With that information, the key manager is able to inflect
>    its usual processing where it selects by default the source address
>    of the SA for the negotiation (i.e. as local address of the IKE_SA).
.. able to change its usual ... ?

>    associated with that SP.  The information SHOUD also be used by the

SHOULD


> A PF_KEY MIGRATE message should be formed, based on security policy
>    configuration and binding record. 

What is a binding record? Do you mean a binding cache entry, or a binding update list entry?

Section 6 should probably be an appendix.

Likewise for Section 7.

I'm not sure I see much value in keeping Section 10 at all.

>    o  Modifications to IPsec stack:
>      *  Processing PF_KEY MIGRATE messages: the kernel should be able
>          to process PF_KEY MIGRATE messages sent by the Mobile IPv6
>          code.  Unless the message is invalid, it should be sent to all
>          open PF_KEY sockets.

Something is missing here. I think you meant to say that once it is processed by the kernel, it shall be copied to all open PF_KEY sockets.

> == The document seems to lack the recommended RFC 2119 boilerplate, even if
>      it appears to use RFC 2119 keywords -- however, there's a paragraph with
>      a matching beginning. Boilerplate error?

(From idnits)

This seems like an error that you should should fix.

>
>  ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301)
>
>  ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306)
>

Please check that you are referring to the RFCs that you wanted to refer to. If there is no specific reason to refer to old ones, please use the new ones instead.

Jari

As per our prior discussions, this is a request to publish http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-01 as an AD-sponsored informational RFC. The write-up is as below:

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

  The Document Shepherd is Julien Laganier. He has personally done
        a thorough review of the document. He believe the document is ready
        for forwarding to IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

        The document was given adequate reviews. The Document Shepherd has
        no concerns about the depth or breadth of these reviews. The mechanism
        described in this memo has been implemented for Linux:

  o  Linux kernel IPsec stack: the mechanism is fully implemented since
      version 2.6.28 (released in December 2008) both for PF_KEY (as
      described in this memo) and Linux native interface (Netlink, see
      [RFC3549]) with in-kernel XFRM transformation framework (basis of
      the IPsec stack).
  o  UMIP (Linux Mobile IPv6 Daemon): the mechanism is fully supported
      for years.  Details and documentation are available at
      http://umip.org.  Linux native interface (Netlink) is used by UMIP
      to pass MIGRATE message to the kernel which passes it after
      processing to registered (PF_KEY and Netlink/XFRM) key managers.
  o  Racoon IKEv1 daemon: the mechanism is fully supported and
      available upstream since 2008.  Racoon relies on PF_KEY for
      communications with the kernel IPsec stack.
  o  StrongSwan IKEv2 daemon for Linux: the mechanism is fully
      supported upstream since version 4.2.9, released in November 2008.
      Support has been developed by StrongSwan's main developers (Martin
      Willi and Andreas Steffen) based on this specification.
      StrongSwan IKEv2 daemon uses Netlink for communications with the
      kernel.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

        The Document Shepherd has no such concerns.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

        The Document Shepherd has no such concerns.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

  This draft is not the product of a specific WG, but has been
        discussed in the MIP6 and MEXT WGs. The draft has received
        support from some WG participants and no opposition.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

        No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

  Yes.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

  Yes.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

        Yes. The Document has no IANA actions.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

        There are no such sections.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

  This document describes the need for an interface between Mobile IPv6
  and IPsec/IKE and shows how the two protocols can interwork.  An
  extension of the PF_KEY framework is proposed which allows smooth and
  solid operation of IPsec/IKE in a Mobile IPv6 environment.

  This document is heavily based on a previous draft [MIGRATE] written
  by Shinta Sugimoto, Masahide Nakamura and Francis Dupont.  It simply
  reuses the MIGRATE mechanism defined in the expired document, removes
  a companion extension (SADB_X_EXT_PACKET) based on implementation
  feedback (complexity, limitations, ...) and fills the gap by very
  simple changes to MIGRATE mechanism.  This results in a more simple
  and consistent mechanism, which also proved to be easier to
  implement.  This document is expected to serve as a continuation of
  [MIGRATE] work.  For that reason, the name of the extension has been
  kept.

  PF_KEY MIGRATE message serves as a carrier for updated information
  for both the in-kernel IPsec structures (Security Policy Database /
  Security Association Database) and those maintained by the key
  managers.  This includes in-kernel Security Policy / Security
  Association endpoints, key manager maintained equivalents, and
  addresses used by IKE_SA (current and to be negotiated).  The
  extension is helpful for assuring smooth interworking between Mobile
  IPv6 and IPsec/IKE for the bootstrapping of mobile nodes and their
  movements.

    Working Group Summary

  This is an individual submission that has been discussed in the

  This draft is not the product of a specific WG, but has been
  discussed in the MIP6 and MEXT WGs. The draft has received
  support from some WG participants and no opposition.

    Document Quality

  The document was given adequate reviews. The Document Shepherd has
  no concerns about the depth or breadth of these reviews. The mechanism
  described in this memo has been implemented for Linux:

  o  Linux kernel IPsec stack: the mechanism is fully implemented since
      version 2.6.28 (released in December 2008) both for PF_KEY (as
      described in this memo) and Linux native interface (Netlink, see
      [RFC3549]) with in-kernel XFRM transformation framework (basis of
      the IPsec stack).
  o  UMIP (Linux Mobile IPv6 Daemon): the mechanism is fully supported
      for years.  Details and documentation are available at
      http://umip.org.  Linux native interface (Netlink) is used by UMIP
      to pass MIGRATE message to the kernel which passes it after
      processing to registered (PF_KEY and Netlink/XFRM) key managers.
  o  Racoon IKEv1 daemon: the mechanism is fully supported and
      available upstream since 2008.  Racoon relies on PF_KEY for
      communications with the kernel IPsec stack.
  o  StrongSwan IKEv2 daemon for Linux: the mechanism is fully
      supported upstream since version 4.2.9, released in November 2008.
      Support has been developed by StrongSwan's main developers (Martin
      Willi and Andreas Steffen) based on this specification.
      StrongSwan IKEv2 daemon uses Netlink for communications with the
      kernel.