Re: [MEXT] AD review of draft-ebalard-mext-pfkey-enhanced-migrate

[[e-mail] (Arnaud Ebalard)]

Hi,

Jari Arkko <[e-mail]> writes:

> 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 <http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-01#ref-hld-sec>]
>
> Its not clear to me why this disabling is required. Can you elaborate?

RFC 4877 has:

   o  When the mobile node returns home and de-registers with the Home
      Agent, the tunnel between the home agent and the mobile node's
      care-of address is torn down.  The security policy entries, which
      were used for protecting tunneled traffic between the mobile node
      and the home agent, SHOULD be made inactive (for instance, by
      removing them and installing them back later through an API).
      ...

The trigger for the removal of the SP is the Home Link Detection
mechanism, i.e. the reception of a RA advertising the home subnet
prefix. Everyone can send such packets and have the MN believe it is at
home. For a MN using IPsec for protecting data traffic, the result is
that it may start sending its data unprotected on a foreign network.
There is more in the draft (associated with the authorized format of
dereg BU) but this is the bottom line.

Note that after publishing hld-sec draft, I was pointed the following
draft: http://tools.ietf.org/html/draft-sheffer-ipsecme-secure-beacon


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

MIPv6 Signaling traffic (BU/BA) is indeed *always* protected with
IPsec. But if you have time to read the draft, you'll discover that
some parts of the specification (3775) and the use of RH2/HAO make it
possible to subvert that protection as long as we manage to have the MN
generate a protected BU.


> And after that, if there is no communication with the home agent, what
> problem is solved by removing the SA/SP?

Tell me if I misunderstand your question: AFAICT, the removal of the
tunnel mode SP/SA protecting data traffic has been specified to prevent
the MN to IPsec-tunnel data traffic to the HA in front of it when it is
at home and simply have its data packets routed via its HA.

To make it simple, I *think* the purpose of this default removal of
tunnel SP/SA is to reduce the load on the HA induced by MN which are at
home (i.e. a somewhat safer place than foreign networks).


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

I can remove the reference if you prefer. It was added at some point
as a pointer in order for the reader interested by MN movements and
IPsec/IKE to be aware of the fact that Home Link Detection mechanism as
defined in base specifications is something heuristic (reception of a RA
with the Home Prefix) which is used as a trigger for something important
security-wise: removal of SP protecting data traffic.


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

Yes. I will s/i.e./e.g./


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

Rereading it, I agree the picture is not clear enough. Below is a
fresh example of the message emitted by the MIPv6 module to the kernel
and received by the IKE daemon when changing CoA (I just somewhat
anonymized addresses). It is followed by a modified version of the
picture. Tell me if you think it provides a better introduction for the
reader (as a side note, a detailed version of the message is found in
Appendix A of the document).

###[ PF_KEY SADB_X_MIGRATE message ]###
  version= 2
  type= SADB_X_MIGRATE
  errno= 0
  satype= SADB_SATYPE_ESP
  len= 40
  res= 0
  seq= 0L
  pid= 0L
###[ PF_KEY Key Manager Addresses extension ]###
     len= 8
     type= SADB_EXT_X_KMADDRESS
     res= 0L
     \local\
      |###[ sockaddr_in6 structure - Linux version ]###
      |  sin6_family= AF_INET6
      |  sin6_port= 0
      |  sin6_flowinfo= 0L
      |  sin6_addr= 2001:db8:1::221:70ff:febd:effb (New CoA)
      |  sin6_scope_id= 0L
     \remote\
      |###[ sockaddr_in6 structure - Linux version ]###
      |  sin6_family= AF_INET6
      |  sin6_port= 0
      |  sin6_flowinfo= 0L
      |  sin6_addr= 2001:db8:2::211:43ff:fe44:e4a0 (HA)
      |  sin6_scope_id= 0L
###[ PF_KEY IPv4/IPv6 source address extension ]###
        len= 5
        type= SADB_EXT_ADDRESS_SRC
        proto= 0
        plen= 0
        res= 0
        \addr\
         |###[ sockaddr_in6 structure - Linux version ]###
         |  sin6_family= AF_INET6
         |  sin6_port= 0
         |  sin6_flowinfo= 0L
         |  sin6_addr= ::
         |  sin6_scope_id= 0L
###[ PF_KEY IPv4/IPv6 destination address extension ]###
           len= 5
           type= SADB_EXT_ADDRESS_DST
           proto= 0
           plen= 128
           res= 0
           \addr\
            |###[ sockaddr_in6 structure - Linux version ]###
            |  sin6_family= AF_INET6
            |  sin6_port= 0
            |  sin6_flowinfo= 0L
            |  sin6_addr= 2001:db8:2::20d:93ff:fe55:8f79 (HoA)
            |  sin6_scope_id= 0L
###[ PF_KEY POLICY extension ]###
              len= 20
              type= SADB_EXT_X_POLICY
              poltype= IPsec
              dir= IN
              res= 255
              id= 0L
              prio= 0L
              \reqs\
               |###[ IPsec Request (sadb_x_ipsecrequest) ]###
               |  len= 72
               |  proto= ESP
               |  mode= Tunnel
               |  level= Require
               |  res1= 0
               |  id= 0L
               |  res2= 0L
               |  \sockaddr1\
               |   |###[ sockaddr_in6 structure - Linux version ]###
               |   |  sin6_family= AF_INET6
               |   |  sin6_port= 0
               |   |  sin6_flowinfo= 0L
               |   |  sin6_addr= 2001:db8:2::211:43ff:fe44:e4a0 (HA)
               |   |  sin6_scope_id= 0L
               |  \sockaddr2\
               |   |###[ sockaddr_in6 structure - Linux version ]###
               |   |  sin6_family= AF_INET6
               |   |  sin6_port= 0
               |   |  sin6_flowinfo= 0L
               |   |  sin6_addr= 2001:db8:1::216:eaff:feec:ae14 (Old CoA)
               |   |  sin6_scope_id= 0L
               |###[ IPsec Request (sadb_x_ipsecrequest) ]###
               |  len= 72
               |  proto= ESP
               |  mode= Tunnel
               |  level= Require
               |  res1= 0
               |  id= 0L
               |  res2= 0L
               |  \sockaddr1\
               |   |###[ sockaddr_in6 structure - Linux version ]###
               |   |  sin6_family= AF_INET6
               |   |  sin6_port= 0
               |   |  sin6_flowinfo= 0L
               |   |  sin6_addr= 2001:db8:2::211:43ff:fe44:e4a0 (HA)
               |   |  sin6_scope_id= 0L
               |  \sockaddr2\
               |   |###[ sockaddr_in6 structure - Linux version ]###
               |   |  sin6_family= AF_INET6
               |   |  sin6_port= 0
               |   |  sin6_flowinfo= 0L
               |   |  sin6_addr= 2001:db8:1::221:70ff:febd:effb (New Coa)
               |   |  sin6_scope_id= 0L

Current version:

    o  Key manager address information                 \
       *  source address                                |  For IKE only
       *  destination address                          /
    o  Selector information:                           \
       *  source address/port                           |
       *  destination address/port                      |
       *  upper layer protocol (i.e., Mobility Header)  |
       *  direction (inbound/outbound)                  |
    o  Old SA information:                              |
       *  old source endpoint address                   |  For IKE and
       *  old destination endpoint address              |  IPsec stack
       *  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)                      /

Proposed update:

    o  Key manager address (SADB_EXT_X_KMADDRESS)      \
       *  source address                                |  For IKE only
       *  destination address                          /
    o  Traffic selectors (SADB_EXT_ADDRESS_{SRC,DST})  \
       *  source address/port                           |
       *  destination address/port                      |
       *  upper layer protocol (i.e., Mobility Header)  |
       *  direction (inbound/outbound)                  |
    o  Policy information (SADB_EXT_X_POLICY)           |
       o  Old IPsec request (sadb_x_ipsecrequest):      |
          *  old source endpoint address                |  For IKE and
          *  old destination endpoint address           |  IPsec stack
          *  IPsec protocol (ESP/AH)                    |
          *  mode (Tunnel/Transport)                    |
       o  New IPsec request (sadb_x_ipsecrequest):      |
          *  new source endpoint address                |
          *  new destination endpoint address           |
          *  IPsec protocol (ESP/AH)                    |
          *  mode (Tunnel/Transport)                   /

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

It's a corner case inherited from PF_KEY spec. It depends on the size of
socket buffers and hence on what userspace does on that aspect. Section
1.4 of RFC 2367 has:

   PF_KEY message delivery is not guaranteed, especially in cases where
   kernel or socket buffers are exhausted and messages are dropped.

You are right that MIPv6 userland process could monitor that the message
is delivered by the kernel but this would not *guarantee* that another
PF_KEY process has indeed received it even if this is likely.

If you think it does not belong to the spec (i.e. we can expect the
reader to be aware of it already), I can remove it.


> Editorial:
>
>>    This document is heavily based on a previous draft [MIGRATE <http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-01#ref-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 <http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-01#ref-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.

I will remove the paragraph from the abstract and change the last
paragraph of section 1 from: 

   As stated in the abstract, this document is heavily based on the
   content of a previous draft [MIGRATE].  This expired memo
   served as the basis for this work both from technical and editorial
   standpoints.  Numerous technical discussions with some of its authors
   took place while working on this memo and associated implementations.

to:

   This document is heavily based on the content of a previous draft
   [OLDMIGRATE]. This expired memo served as the basis for this work
   both from technical and editorial standpoints. Numerous technical
   discussions with some of its authors took place while working on
   this memo and associated implementations.

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

will replace it by "Security Policy (SP)"


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

Ack.


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

Yes. Will use "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

Ack.


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

Based on which side (MN or HA/CN) we are considering, either BULe or BCe
respectively. I will change that to:

and binding record (e.g. Binding Update List entry on the MN, Binding
Cache entry on the HA)


> Section 6 should probably be an appendix.
>
> Likewise for Section 7.

ok.


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

Except for the last point of the list in section 10:

  o  Currently, large portion of the proposed mechanism is
     implementation dependent due to lack of standard interface
     to access the SPD (PF_POLICY?).

everything is already in the document so I guess we can remove it w/o
issues.

If you think it may help the reader I will just put somewhere in the
document a pointer to the following (obviously non-normative) reference:

 http://www.kame.net/newsletter/20021210/
 http://tools.ietf.org/html/draft-schilcher-mobike-pfkey-extension-01

This gives some good explanation and introduction of what is already in
major PF_KEY implementations (Linux, BSD) to deal with SPD.

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

Yes, should is wrong. Will modify last sentence as follows: "Unless the
message is invalid, 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?

yep. Will correct that.

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

I will remove the reference to RFC 2401 which is due to:

   be updated.  Basically the information should contain necessary
   elements which characterize traffic selector as specified in the
   IPsec architecture ([RFC2401], [RFC4301]).  With regard to the upper
   layer protocol, when the Mobile IPv6 stack is not fully aware of

For RFC 2409, it is due to the link in the terminology section:

   In this document, the term IKE implicitly stands for both IKEv1
   [RFC2409] and IKEv2 [RFC5996].  IKEv2 terminology is used
   preferentially when describing actions performed by the key manager
   but they also apply to the IKEv1 counterparts.  For instance, when
   actions occur on IKE_SA, they also apply to ISAKMP SA for IKEv1,
   except otherwise specified.  The terms "IKE daemon" and "Key Manager
   (KM)" are used interchangeably in the document.

I think it makes sense to keep it that way. Note that idnits seems
unaware of the fact that 4306 has been obsoleted by RFC 5996 ;-)

Thanks for your time and effort, Jari.

Cheers,

a+