Subject: [MEXT] Comments on draft-ietf-mext-nemo-v4traversal-06.txt

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 03 Dec 2008 10:32:53 -0800

Hi Hesham,

Four weeks ago, I posted the following comments, questions and
corrections on version 6 of draft-ietf-mext-nemo-v4traversal w/o
any response so far. Did my email slipped through?

> 2.1.  Motivation for Using Mobile IPv6 Only
>
>    IPv6 offers a number of improvements over today's IPv4, primarily due
>    to its large address space.  Mobile IPv6 offers a number of
>    improvements over Mobile IPv4 [RFC3344], mainly due to capabilities
>    inherited from IPv6.  For instance, route optimization and dynamic
>    home agent discovery can only be achieved with Mobile IPv6.
>
>    One of the advantages of the large address space provided by IPv6 is
>    that it allows mobile nodes to obtain a globally unique care-of
>    address wherever they are.  Hence, there is no need for Network
>    Address Translator (NAT) traversal techniques designed for Mobile
>    IPv4.  This allows Mobile IPv6 to be a significantly simpler and more
>    bandwidth efficient mobility management protocol.  At the same time,
>    during the transition towards IPv6, NAT traversal for existing
>    private IPv4 networks needs to be considered.  This specification
>    introduces NAT traversal for this purpose.
>
>    The above benefits make the case for using Mobile IPv6 only for dual
>    stack mobile nodes in order to allow for a long lasting mobility
>    solution and minimize the need to changing the mobility stack due to
>    the introduction of IPv6 within a deployed network.

 Perhaps it is just my english, but I fail to understand last paragraph.

> 3.2.  Mobile Prefix Solicitation and Advertisement
>
>    According to [RFC3775], the mobile node can send a Mobile Prefix
>    Solicitation and receive a Mobile Prefix Advertisement containing all
>    prefixes advertised on the home link.
>
>    A dual stack mobile node MAY send a Mobile Prefix Solicitation
>    message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where
>    the mobile node has no access to IPv6 within the local network.
>    Securing these messages requires the mobile node to have a security
>    association with the home agent, using IPsec (AH or ESP) and based on
>    the mobile node's IPv4 care-of address as described in [RFC3775].
>    Since the mobile node needs to encapsulate all IPv6 traffic sent to
>    the home agent into IPv4 while located in an IPv4-only visited
>    network, this SA would match all packets if the selectors were based
>    on the information in the outer header.  That is, the SA selectors
>    being the protocol number (protocol is always IP in IP), as well as,
>    source and destination addresses are all common to all packets.

 Possibly me but last sentence seems incorrect. If not, what is its
 meaning?

>    If
>    this effect is not desired, the mobile node can base the SA on the
>    information in the inner header (i.e., using the home agent's IPv6
>    address, the mobile node's home address and the ICMP protocol
>    number).  This security association would use transport mode ESP
>    protection.

 Not clear, IMHO.

> 3.3.1.  Foreign Network Supports IPv6
>
>    In this case, the mobile node is able to configure a globally unique
>    IPv6 address.  The mobile node will send a binding update to the IPv6
>    address of its home agent, as defined in [RFC3775].  The binding
>    update MAY include the IPv4 home address option introduced in this
>    document.  After receiving the binding update, the home agent creates
>    two binding cache entries, one for the mobile node's IPv4 home
>    address, and another for the mobile node's IPv6 home address.  Both
>    entries will point to the mobile node's IPv6 care-of address.  Hence,
>    whenever a packet is addressed to the mobile node's IPv4 or IPv6 home
>    addresses, the home agent will tunnel it in IPv6 to the mobile node's
>    IPv6 care-of address included in the binding update.  Effectively,
>    the mobile node establishes two different tunnels, one for its IPv4
>    traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6)
>    with a single binding update.
>
>    In this scenario, the only addition to [RFC3775] is the inclusion of
>    the IPv4 home address option in the binding update message.
>
>    After accepting the binding update and creating the corresponding
>    binding cache entries, the home agent MUST send a binding
>    acknowledgement to the mobile node as defined in [RFC3775].  In
>    addition, if the binding update included an IPv4 home address option,
>    the binding acknowledgement MUST include the IPv4 address
>    acknowledgment option as described later in this specification.  This
>    option informs the mobile node whether the binding was accepted for
>    the IPv4 home address.  If this option is not included in the binding
>    acknowledgement and the IPv4 home address option was included in the
>    binding update, the mobile node MUST assume that the home agent does
>    not support the IPv4 home address option and therefore SHOULD NOT
>    include the option in future binding updates to that home agent
>    address.
>
>    When a mobile node acquires both IPv4 and IPv6 care-of addresses at
>    the foreign network, it SHOULD prioritize the IPv6 care-of address
>    for it MIPv6 its binding.

 Last sentence seems incorrect.

> 4.1.2.  The IPv4 Care-of Address Option
>
>    This option is included in the Mobility Header including the binding
>    update message sent from the mobile node to a home agent or Mobility
>    Anchor Point.  The alignment requirement for this option is 4n.
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Type        |   Length      |         Reserved              |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     IPv4 Care-of address                      |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>                        Figure 2: The IPv4 CoA Option
>
>    Type
>
>       TBD
>
>    Length
>
>       6
>
>    Reserved
>
>       This field is set to zero by the sender and ignored by the
>       receiver.
>
>
>
>
> Soliman                    Expires May 7, 2009                 [Page 15]
> 
> Internet-Draft                   dsmipv6                   November 2008
>
>
>    IPv4 Care-of Address
>
>       This field contains the mobile node's IPv4 care- of address.  The

                                                    care-of

> 5.2.  NAT Detection
>
>    This section deals with NAT detection for the purpose of
>    encapsulating packets between the mobile node and the home agent.
>    Mobile IPv6 uses IKEv2 to establish te IPsec security association
>    between the mobile node and the home agent.

 IKE is not mandatory, it is only optional. Or did I missed a reference
 document?

 What about 'may use IKE ...'

>    IKEv2 has its own NAT detection mechanism.  However, IKEv2's NAT
>    detection is only used for the purpose of setting up the IPsec SA
>    for secure traffic.  The interactions between the two NAT traversal
>    mechanisms are described in Section 6
>
>    NAT detection is done when the initial binding update message is sent
>    from the mobile node to the home agent.  When located in an IPv4-only
>    foreign link, the mobile node sends the binding update message
>    encapsulated in UDP and IPv4.  The source address of the IPv6 packet
>    is the mobile node's IPv6 home address.  The destination address is
>    the IPv6 address of the home agent.  The IPv4 header contains the
>    IPv4 care-of address in the source address field and the IPv4 address
>    of the home agent in the destination address field.
>
>    When the home agent receives the encapsulated binding update, it
>    compares the IPv4 address of the source address field in the IPv4
>    header with the IPv4 address included in the IPv4 care-of address
>    option.  If the two addresses match, no NAT device was in the path.
>    Otherwise, a NAT device was in the path and the NAT detection option
>    is included in the binding acknowledgement.  The binding
>    acknowledgement, and all future packets, are then encapsulated in UDP
>    and IPv4.  The source address in the IPv4 header is the IPv4 address
>    of the home agent.  The destination address is the IPv4 address
>    received in the IPv4 header encapsulating the binding update (this
>    address will be different from the IPv4 care-of address when a NAT is
>    in the path).  The source port in the packet is the home agent's
>    source port.  The destination port is the source port received in the
>    binding update message.  Note that the home agent stores the port
>    numbers and associates them with the mobile node's tunnel in order to
>    forward future packets.
>
>    Upon receiving the binding acknowledgement with the NAT detection
>    option, the mobile node sets the tunnel to the home agent to UDP
>    encapsulation.  Hence, all future packets to the home agent are
>    tunneled in UDP and IPv4.  For all tunneled IPv6 packets, the source
>    address in the IPv6 header is the mobile node's IPv6 home address and
>    the destination address is the correspondent node's IPv6 address.
>    All tunneled IPv4 packets will contain the mobile node's IPv4 home
>    address in the source address field of the inner IPv4 packet and the
>    correspondent node's IPv4 address in the destination address field.
>    The outer IPv4 header is the same whether the inner packet is IPv4 or
>    IPv6.
>
>    If no NAT device was detected in the path between the mobile node and
>    the home agent then IPv6 packets are tunneled in an IPv4 header,
>    unless the home agent forces UDP encapsulation using the F flag.  The
>    content of the inner and outer headers are identical to the UDP
>    encapsulation case.

 What if filtering somewhere prevents IP over IP but is fine with UDP
 encapsulated traffic. If the HA decides to go for IP over IP (i.e. does
 not force the F flag), this will not work.

> 5.4.1.  Selecting a Care-of address
>
>    When a mobile node is in a dual stacked visited network, it will have
>    a choice between an IPv4 and an IPv6 care-of address.  The mobile
>    node SHOULD prefer the IPv6 care-of address and bind it to its home
>    address(es).  If a mobile node attempted to bind the IPv6 care-of
>    address to its home address(es) and the binding update timed out, the
>    mobile node SHOULD:
>
>    o  Resend the binding update using the exponential back-off algorithm
>       described in [RFC3775].
>
>    o  If after three attempts in total a binding acknowledgement was not
>       received, the mobile node SHOULD send a new binding update using
>       the IPv4 care-of address.  The exponential backoff algorithm
>       described in [RFC3775] should be used for re-transmission of the
>       binding update if needed.
>
>    This procedure should be used to avoid scenarios where IPv6
>    connectivity may not be as reliable as IPv4.  This may take place
>    during early deployments of IPv6, or simply due to temporary outages
>    affecting IPv6 routing.
>
>    It is RECOMMENDED that upon movement the mobile node does not change
>    the IP address family chosen for the previous binding update unless
>    the mobile node is aware that it has moved to a different
>    administrative domain where previous problems with IPv6 routing may
>    not be present.  Repeating the above procedure upon every movement
>    can cause significant degradation of the mobile node's applications'
>    performace due to extended periods of packet losses after handover if
>    the routing outage is still in effect.
>
>    When using an IPv4 care-of address and IP in IP encapsulation, if the
>    mobile node implementation is made aware by upper layers of
>    persistent packet losses , it may attempt to resend the binding
>    update with the F flag set, requesting UDP encapsulation for all
>    packets.  This may avoid packet losses due to situations where local
>    firewalling policies prevent the use of IP in IP encapsulation.
>
>    The effect of these address selection mechanism is to allow the
>    follwing preferences:

      following

> 6.  Security Considerations
>
>    This specification allows a mobile node to send one binding update
>    for its IPv6 and IPv4 home addresses.  This is a slight deviation
>    from [RFC3775] which requires one binding update per home address.
>    However, like [RFC3775], the IPsec security association needed to
>    authenticate the binding update is still based on the mobile node's
>    IPv6 home address.  Therefore, in order to authorize the mobile
>    node's IPv4 home address binding, the home agent MUST store the IPv4
>    address corresponding to the IPv6 address that is allocated to a
>    mobile node.  Therefore, it is sufficient for the home agent to know
>    that the IPsec verification for the packet containing the binding
>    update was valid provided that it knows which IPv4 home address is
>    associated with which IPv6 home address.  Hence, the security of the
>    IPv4 home address binding is the same as the IPv6 binding.
>
>    In effect, associating the mobile node's IPv4 home address with its
>    IPv6 home address moves the authorization of the binding update for
>    the IPv4 address to the Mobile IPv6 implementation, which infers it
>    from the fact that the mobile node has an IPv6 home address and the
>    right credentials for sending an authentic binding update for the
>    IPv6 address.

 ok.

>    In cases where this specification is used for NAT traversal, it is
>    important to note that it has the same vulnerabilities associated
>    with [RFC3519].  An attacker is able to hijack the mobile node's
>    session with the home agent if it can modify the contents of the
>    outer IPv4 header.  The contents of the header are not authenticated
>    and there is no way for the home agent to verify their validity.
>    Hence, a man in the middle attack where a change in the contents of
>    the IPv4 header can cause a legitimate mobile node's traffic to be
>    diverted to an illegitimate receiver independently of the
>    authenticity of the binding update message.
>
>    In this specification, the binding update message MUST be protected
>    using ESP transport mode.

 Just to be sure: IP / UDP / IPv6 / ESP / MH ?

>     When the mobile node is located in an
>    IPv4-only network, the binding update message is encapsulated in UDP
>    as described earlier.  However, UDP SHOULD NOT be used to encapsulate
>    the binding update message when the mobile node is located in an
>    IPv6-enabled network.  If protection of payload traffic is needed
>    when the mobile node is located in an IPv4-only network,
>    encapsulation is done using tunnel mode ESP over port 4500 as
>    described in [RFC3948].  During the IKE negotiation with the home
>    agent, if the mobile node and home agent support the use of port
>    4500, the mobile node MUST establish the security association over
>    port 4500, regardless of the presence of a NAT.  This is done to
>    avoid the switching between ports 500 and 4500 and the potential
>    traffic disruption resulting from this switch.

 Is this summary correct for a MIPv6 MN that uses IPsec for both
 signaling and data (payload) on an IPv4 network:

 - signaling: IP / UDP / IPv6 / ESP / MH
 - data: IP / UDP / ESP / IPv6 / L4

> 6.1.  Handover Interactions for IPsec and IKE
>
>    After the mobile node detects movement it configures a new care-of
>    address.  If the mobile node is in an IPv4-only network, it removes
>    binding update list entries for correspondent nodes since route
>    optimisation cannot be supported.  This may cause inbound packet
>    losses as remote correspondent nodes are unaware of such movement.
>    To avoid confusion in the correspondent node, the mobile node SHOULD
>    deregister its binding with each correspondent node by sending a
>    deregistration binding update.  The deregistration binding update
>    message is tunnelled to the home agent and onto the correspondent
>    node.  This is done after the mobile node updates the home agent with
>    its new location as discussed below.
>
>    The mobile node sends the binding update message to the home agent.
>    If the mobile node is in an IPv6-enabled network, the binding update
>    is sent without IPv4/UDP encapsulation.  If the mobile node is in an
>    IPv4-only network, then after IPsec processing of the BU message, it
>    encapsulates the BU in UDP/IPv4 as discussed in sections 5.2 and 5.4.
>    In order to be able to send the binding update while in an IPv4-only
>    network, the mobile node needs to use the new IPv4 care-of address in
>    the outer header, which is different from the care-of address used in
>    the existing tunnel.  This should be done without permanently
>    updating the tunnel within the mobile node's implementation in order
>    to allow the mobile node to receive packets on the old care-of
>    address until the binding acknowledgement is received.  The method
>    used to achieve this effect is implementation dependent and is
>    outside the scope of this specification.  This implies that the IP
>    forwarding function (which selects the interface or tunnel through
>    which a packet is sent) is not based solely on the destination
>    address: some IPv6 packets destined to the home agent are sent via
>    the existing tunnel, while BUs are sent using the new care-of
>    address.  Since BUs are protected by IPsec, the forwarding function
>    cannot necessarily determine the correct treatment from the packet
>    headers.  Thus, the DSMIPv6 implementation has to attach additional
>    information to BUs, and this information has to be preserved after
>    IPsec processing and made available to the forwarding function, or
>    additional DSMIP processing added to the forwarding function.
>    Depending on the mobile node's implementation, meeting this
>    requirement may require changes to the IPsec implementation.
>
>    Upon receiving the binding update message encapsulated in UDP/IPv4,

                                                                IPv4/UDP

>    the home agent processes it as follows.  In order to allow the
>    DSMIPv6 implementation in the home agent to detect the presence of a
>    NAT on the path to the mobile node, it needs to compare the outer
>    IPv4 source address with the IPv4 address in the IPv4 care-of address
>    option.  This implies that the information in the outer header will
>    be preserved after IPsec processing and made available to the DSMIPv6
>    implementation in the home agent.  Depending on the home agent's
>    implementation, meeting this requirement may require changes to the
>    IPsec implementation.
>
>    The home agent updates its tunnel mode security association to
>    include the mobile node's care-of address as the remote tunnel header
>    address, and 4500 as the port number.  The IPv4 address and port
>    number are likely to be wrong; the mobile node provides the correct
>    information in a separate exchange as described below.  When the
>    mobile node is located in a private IPv4 network (which is detected
>    as described above), the new address and port number are allocated by
>    the NAT.  The home agent will also enable or disable UDP
>    encapsulation for outgoing ESP packets for the purpose of NAT
>    traversal.
>
>    If the Key Management Mobility Capability (K) bit was set in the
>    binding update, and the home agent supports this feature, the home
>    agent updates its IKE security associations to include the mobile
>    node's care-of address as the peer address and 4500 as the port
>    number.

 How?

>    The home agent may also need to change NAT traversal fields
>    in the IKE_SA to enable the dynamic update of the IP address and port
>    number based on the reception of authenticated IKE messages, or

 Following standard IKE procedure (i.e. 2.23 of RFC 4306) or is something
 else expected?

>    authenticated packets using tunnel mode ESP.

 How?

>    The dynamic updates are described in section 2.23 of RFC 4306.

 For IKE, yes. For other cases, it is not.

>    As described above, when the
>    mobile node is located in a private IPv4 network, the address and
>    port number used for IPsec and IKE traffic is not yet known by the
>    home agent at this point.
>
>    The mobile node updates the IKE SA in one of two ways.  If the K flag
>    was set in the binding acknowledgement message, the mobile node
>    SHOULD send an empty informational message,

 How does the MIPv6 modules manages to tell the IKE module to do that?

>     which results in the IKE
>    module in the home agent to dynamically update the SA information.
>    The IKE implementation in the home agent is REQUIRED to support this
>    feature.

 You mean on the MN, the HA or both?

>    Alternatively, the IKE SA should be re-negotiated.  Note
>    that updating the IKE SA MUST take place after the mobile node has
>    sent the binding update and received the acknowledgement from the
>    home agent.
>
>    It is important to note that the mobile node's IPv4 care-of address
>    seen by the DSMIPv6 module in the home agent upon receiving the
>    binding update may differ from the IPv4 care-of address seen by the
>    IKE module and the care-of address used for forwarding IPsec tunnel
>    mode traffic.  Hence, it is probable that different modules in the
>    home agent will have a different care-of address that should be used
>    for encapsulating traffic to the mobile node.

 What does last sentence means?

>    After successfully processing the binding update, the home agent
>    sends the binding acknowledgement to the mobile node's care-of
>    address as received in the outer header of the packet containing the
>    binding update.  Note that if the BU was rejected, the BAck is sent
>    to the same address where the BU was received from.  This may require
>    special treatment in IP forwarding and/or IPsec processing which
>    resembles sending of BUs in the mobile node (described above).
>
>    Upon receiving the binding acknowledgement, the mobile node updates
>    its local tunnel mode Security Association information to include the
>    tunnel header IP source address, which is the mobile node's address
>    and the tunnel header IP destination, which is the home agent's
>    address.  The mobile node may also need to enable or disable UDP
>    encapsulation for outgoing ESP packets for the purpose of NAT
>    traversal and the sending of keep alives.

 How? 

>    The mobile node MAY use [RFC4555] to update its IKE SA with the home
>    agent.  Using MOBIKE requires negotiating this capability with the
>    home agent when establishing the SA.  In this case, the mobile node
>    and the home agent MUST NOT update their IPsec SAs locally as this
>    step is performed by MOBIKE.  Furthermore, the use of MOBIKE allows
>    the mobile node to update the SA independently of the binding update
>    exchange.  Hence, there is no need for the mobile node to wait for a
>    binding acknowledgement before performing MOBIKE.  The use of MOBIKE
>    is OPTIONAL in this specification.

 How IKE module and MIPv6 do synchronize on which address to use? More
 precisely, how is MIPv6 module expected to tell IKE implementation to
 use the correct address for update in MOBIKE context. 

> 6.2.  IKE negotiation messages between the mobile node and Home Agent
>
>    This specification defines a number of possible data encapsulation
>    formats depending on the mobile node's connectivity to the visited
>    network.  When connected to an IPv6-enabled network, the tunnelling
>    formats are clear.  However, when connected to an IPv4-only network,
>    care should be taken when negotiating the IKE association and the
>    consequential tunnelling formats used for secure and insecure
>    traffic.  This section illustrates the IKE message exchange between
>    the mobile node and home agent when the mobile node is located in an
>    IPv4-only network.  Two different IKE negotiations are considered:
>
>    o  IKEv2 operation for securing DSMIPv6 Signaling.
>
>    o  IKEv2 operation for securing Data over IPv4
>
> 6.2.1.  IKEv2 Operation for Securing DSMIPv6 Signaling
>
>    A mobile node connected to an IPv4-only network SHOULD follow the
>    procedures described below in order to establish an SA for the
>    protection of binding update and binding acknowledgement messages.
>
>    Mobile Node                      Home Agent
>    -----------                      ----------
>    IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
>     UDP (500, 500) HDR, SAi1, KEi, Ni
>      NAT-D, NAT-D -->
>
>    <- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
>             UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ]
>              NAT-D, NAT-D
>
>    IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
>      UDP (4500,4500) <non-ESP Marker > HDR, SK
>      {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE),
>      SAi2, TSi, TSr}
>     -->
>
>    <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
>            UDP (4500,Y) <non-ESP Marker > HDR, SK
>            {IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE),
>            SAr2, TSi, TSr}
>
>
>    The corresponding SPD entries are shown below.
>
>    Mobile node SPD-S:
>
>       IF local_address = home_address_1 &
>
>       remote_address = home_agent_1 &
>
>       proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use
>       SA ESP transport mode
>
>       Initiate using IDi = user_1 to address home_agent_1
>
>    Home Agent SPD-S:
>
>       IF local_address = home_agent_1 &
>
>       remote_address = home_address_1 &
>
>       proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use
>       SA ESP transport mode
>
>    where home_address_1 is the mobile node's registered IPv6 home
>    address and home_agent_1 is the IP address of the home agent

 Maybe it is a dumb question: How will the IKE daemon know how to contact
 the HA (i mean decide to use V4ADDR as source and HAADDR as
 destination)?

>    The above should result in BU/BA messages with the following BU
>    received by the home agent.
>
>       IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
>
>       UDP header (sport=Z, dport=DSMIPv6)
>
>       IPv6 header (src=V6HOA, dst=HAADDR)
>
>       ESP Header in Transport Mode
>
>       Mobility header
>
>       BU [IPv4 HAO]
>
>       IPv4 CoA option
>
>       (+ other as needed)
>
>    At the home agent, following UDP de-capsulation, the binding update
>    is delivered to the IPsec module as shown below:
>
>       IPv6 header (src=V6HOA, dst=HAADDR)
>
>       ESP Header in Transport Mode
>
>       Mobility header
>
>       BU [IPv4 HAO]
>
>       IPv4 CoA option
>
>       (+other as needed)
>
>    In addition, V4ADDR and the sport (Z) need to be passed with the
>    packet to ensure correct processing.
>
>    Following IPsec processing, the binding update is delivered to the
>    DSMIPv6 home agent module as follows:
>
>       IPv6 header (src=V6HOA, dst=HAADDR)
>
>       Mobility Header
>
>       BU [IPv4 HAO]
>
>       IPv4 CoA option
>
>       (+other as needed)
>
>    In addition, V4ADDR and the sport (Z) need to be passed with the
>    packet to ensure correct processing.
>
>    The binding acknowledgement sent by the home agent module to the
>    IPsec module is as follows:
>
>       IPv6 header (src=HAADDR, dst=V6HOA)
>
>       Mobility Header
>
>       BA ([IPv4 ACK], NAT DET)
>
>       (+ other as needed)
>
>    In addition, V4ADDR, the sport from the BU (Z), and an indication
>    that vanilla UDP encapsulation must be used, need to be passed with
>    the packet to ensure correct processing.
>
>    The binding acknowledgement sent by the home agent to the mobile node
>    is as follows:
>
>       IPv4 header (src= HA_V4ADDR, dst=V4ADDR)
>
>       UDP Header (sport=DSMIPv6, dport=Z)
>
>       IPv6 header (src=HAADDR, dst=V6HOA)
>
>       ESP Header in Transport Mode
>
>       Mobility Header
>
>       BA ([IPv4 ACK], NAT DET)
>
> 6.2.2.  IKEv2 Operation for Securing Data over IPv4
>
>    To secure data traffic when the mobile node is located in an IPv4-
>    only network, the mobile node MUST establish a child_SA for that
>    purpose.  The procedure is as follows:
>
>    Mobile Node                      Home Agent
>    -----------                      ----------
>    IPv4(source_addr=V4ADDR, dest_addr=HAADDR)
>     UDP (4500,4500) < non-ESP Marker > HDR, SK
>      {[N], SA, Ni, [KEi], TSi, TSr}    -->
>
>    <--IPv4(source_addr=HAADDR, dest_addr=V4ADDR)
>           UDP (4500,Y) < non-ESP Marker > HDR, SK
>            SA, Nr, [KEr], TSi, TSr}
>
>
>    If no NAT is detected, the encapsulation used will be:
>
>       IPv4 (source_addr=v4CoA, dest_addr=HAAddr)
>
>       ESP
>
>       IP (source_addr=HoA, set_addr=CNAddr)
>
>       Upper_layer_HDR
>
>       where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA
>
>    If a NAT were detected, the encapsulation used will be:
>
>       IPv4 (source_addr=v4Addr, dest_addr=HAAddr)
>
>       UDP (sport=Y, dport=4500)
>
>       ESP
>
>       IP (source_addr=HoA, set_addr=CNAddr)
>
>       Upper_layer_HDR
>
>    Where v4CoA may be the external IPv4 address of the NAT, IP is either
>    an IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA.
>    The above format shows the packet as seen by the home agent.
>
>    The SPD, whether a NAT were detected or not, is set as follows.  Note
>    that this rule is designed to match all data from the MN to nodes
>    other than the home agent.  This is done so that this rule does not
>    overlap with the earlier rule securing BU/BA signaling between the MN
>    and the HA.
>
>    Mobile Node SPD-S:
>
>       IF local_address = home_address &
>
>       remote_address != home_agent &
>
>       proto=any, then use SA ESP tunnel mode
>
>       Initiate using IDi = user_1 to address home_agent_1
>
>    home agent SPD-S:
>
>       IF local_address != home_agent &
>
>       remote_address = home_address &
>
>       proto=any, then use SA ESP tunnel mode
>
>    Where home_address is the MN's registered IPv6 or IPv4 home address
>    and home_agent is the IPv6 or the IPv4 address of the home agent.

Cheers,

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

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 04 Dec 2008 12:30:24 +1100

No it didn't slip through, I'm waiting to collect all comments for the next
rev. 

Hesham

---

From: Joel Hortelius <[email-masked]>
Date: Thu, 04 Dec 2008 11:35:02 +0000

I'd still like to request that the prefix flag is introduced in the Home
Address Acknowledgement reply, and that it's set to match the flag in
the request. This would allow the prefix length to always be set to the
correct prefix for that particular address providing all relevant
information during the initial exchange.

It would make it much easier to handle configuration of
interfaces/addresses of mobile nodes without having to retrieve the
information from an external source, it'd also make it easier to deal
with the DHCP server support in draft-ietf-netlmm-pmip6-ipv4-support-06,
where the default gateway is provided as an extra option, but the subnet
is unknown since it'll always be 32 in the ack since the P flag is 0.

Regards,
Joel Hortelius.

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 04 Dec 2008 22:20:26 +1100

> information during the initial exchange.

=> I don't understand this. The P flag is not for the pref-len. The pref-len
is returned in the Ack. Can you clarify what you mean?

Hesham

---

From: Joel Hortelius <[email-masked]>
Date: Thu, 04 Dec 2008 12:44:13 +0000

As I understand the specification; If you allocate a single v4 home
address, the P flag is 0, the prefix length is 32,  - In the ack, the
home address is specified, the prefix length is 32.

If you allocate a prefix, P is 1, prefix length is requested value, in
the ack the prefix length is the requested value.

My wish is that the acknowledgement would contain the P flag as well,
indicating that this is indeed a prefix allocation, and if the P flag is
cleared, its a single home address. The prefix length would be the
correct value in both cases, i.e. prefix length in the P=1 case, and the
subnet the home address belongs to when P=0.

It would provide me with information that would be very helpful, that
I'd otherwise would have to try invent some external mechanism or
configuration in order to retrieve since it's very useful to have both
regarding interface configuration in the mobile node and DHCP
configuration in NETLMM/PMIPV6/V4.

I also have a question regarding:
3.1.1 & 4.5;

3.1.1:
Pref                 The length of the prefix allocated to the mobile
                        node. If only a single address is allocated,
                        this field MUST be set to 32. In the first
                        binding update requesting a prefix, the field
                        contains the prefix length requested. However,
                        in the following binding updates, this field
                        must contain the length of the prefix allocated.

                        A value of zero is invalid and MUST be
                        considered an error.

4.5:
- If the IPv4 home address option contained the unspecified IPv4
     address, the home agent SHOULD dynamically allocate an IPv4 home
     address to the mobile node. If none is available, the home agent
     MUST return error code 132 in the status field of the IPv4 address
     acknowledgement option. If a prefix were requested, the home agent
     MUST allocate a prefix with the requested length; otherwise the
     home agent MUST indicate failure of the operation with the
     appropriate error code.

Reading 3.1.1 I get the feeling that the prefix length can be altered in the ack by the home agent. 
But reading 4.5 it's indicated that the home agent MUST allocate the prefix using the requested
length?

Regards,
/J.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 05 Dec 2008 01:37:27 +1100

> home address is specified, the prefix length is 32.

=> Yes.

> cleared, its a single home address.

=> But that's redundant information, you already know that from the pref-len
field.

The prefix length would be the
> configuration in NETLMM/PMIPV6/V4.

=> I'm sorry, I have no idea what you're referring to. If the home address
is not derived from the prefix then you will have two IPv4 HoA options in
the BU. Otherwise there is one option with a prefix that is used to derive
the HoA or just a /32 address. I really don't understand what valuable
information you're after from the P flag.

> I also have a question regarding:

=> Yes you're right, I think 4.5 should be a SHOULD. The MUST is
unnecessarily strong. I'll make that change.

Hesham

---

From: Joel Hortelius <[email-masked]>
Date: Thu, 04 Dec 2008 16:01:09 +0000

> => But that's redundant information, you already know that from the pref-len

But the pref-len field in a single Home Address (not a prefix) would
always be 32? I'm interested in receiving the prefix len of the subnet
the Home Address belongs to

> information you're after from the P flag.

To be honest, I don't understand how to receive the prefix length of a
non-prefix address;

In the BU;
HoA=0.0.0.0, Pref-len=32, P=0
In the BA:
HoA=X.X.X.X, Pref-len=32

If HoA was allocated from a subnet such as X.X.X.0/24, I'd like to
receive the /24 as well.

Otherwise, in order to receive the /24 I'd have to allocate an entire v4
prefix and derive a home address from that even though I'm only
interested in acquiring a single v4 for the mobile node.

I may have misunderstood something, of course, but for me the following
transaction would make more sense:

In the BU;
HoA=0.0.0.0, Pref-len=0, P=0
In the BA:
HoA=X.X.X.X, Pref-len=24, P=0

It would allow me to retrieve a single v4 HoA, and the size of the
subnet it belongs to - making it easier to configure the networks on the
MAG/Mobile Node.

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 05 Dec 2008 09:27:08 +1100

> To be honest, I don't understand how to receive the prefix length of a

=> Ah, well, you don't. This specification doesn't give you that. This has
nothing to do with the P flag. You're looking for a netmask. We didn't
include that in the spec actually. I guess you're asking for a new feature.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 08 Dec 2008 17:08:34 +1100

>  Perhaps it is just my english, but I fail to understand last paragraph.

=> Well, it's a very long sentence! I'll clean up.

>  Possibly me but last sentence seems incorrect. If not, what is its

=> It means that the SA selectors would be the same for all packets.

>  Last sentence seems incorrect.

=> why? It looks good to me.

>  IKE is not mandatory, it is only optional. Or did I missed a reference

=> Yes it's mandatory. I think there is a reference, if not, it will be
added.

>  What about 'may use IKE ...'

=> No I don't think that's right.

>  not force the F flag), this will not work.

=> Please see the latest draft. There is a new section on this. Ultimately,
if the MN wants to force the F flag and the HA doesn't then the HA wins.
This is the nature of the protocol, the HA decides.

=> Yes.

>>    node's care-of address as the peer address and 4500 as the port

=> It's an internal API in the HA. This is not new, the K flag is in RFC
3775.

>  Following standard IKE procedure (i.e. 2.23 of RFC 4306) or is something

=> Yes, same as standard IKE.

>>    authenticated packets using tunnel mode ESP.

=> How what? 

>  For IKE, yes. For other cases, it is not.

=> What other cases? We only support IKE.

>  How does the MIPv6 modules manages to tell the IKE module to do that?

=> See above, this is an assumed API based in 3775.

>  You mean on the MN, the HA or both?

=> It says the HA.

>  What does last sentence means?

=> It means that IKE will see a different address for the MN from the HA's
module. This is because NAT allocates different IP addresses.

>>    traversal and the sending of keep alives.

=> I'm not really sure what you're asking about, please be specific.

>  use the correct address for update in MOBIKE context.

=> We do assume internal APIs between MIPv6 and IKE.

Hesham

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 09 Dec 2008 19:38:46 -0800

Hi Hesham,

Sorry for the latency. Some answers to your questions and additional
comments below. I hesitated to add the chairs in CC of my reply to
clarify the situation (on the API assumption, on the IKE requirement,
...). Don't hesitate if you think my comments make sense. 

> => It means that the SA selectors would be the same for all packets.

ok. Maybe it was me.

> => why? It looks good to me.

s/for it MIPv6 its binding/for its MIPv6 binding/    no?

> => Yes it's mandatory. I think there is a reference, if not, it will be

In MIPv6, support for static keying is mandatory. Dynamic keying is only
optional. Otherwise, I definitely need a pointer. Note that I would also
prefer having IKE mandatory w/ MIPv6 ...

> => No I don't think that's right.

Well, if you make IKE a requirement in DSMIPv6, you are indeed right.

> This is the nature of the protocol, the HA decides.

ok. Will try and take a look.

> => It's an internal API in the HA. This is not new, the K flag is in RFC

"internal API" meaning "implementation dependent feature", i.e. not
specified in MIPv6 documents. 

>>>    authenticated packets using tunnel mode ESP.

I mean: How is the IKE daemon expected to find out which addresses and
ports to use? Can you take as example a MN w/ multiple interfaces? How
does it know which ones have been selected by the HA?

> => See above, this is an assumed API based in 3775.

As stated before, it is left as an implementation dependent issue. In
the end, the result of this hypothesis/lack leads to:

1) inability to have different IKE and MIPv6 implementations work
   together out of the box on a given system.
2) assumption that IKE and MIPv6 modules are implemenented together,
   i.e. are part of the same module. AFAICT, this is a trend in recent
   MIPv6 documents that deal with IPsec/IKE.

Don't hesitate to correct me on that.

>>  You mean on the MN, the HA or both?

That's what I thought. What's the point in requiring *only* the HA to
support that? What is the reason not to require that for the MN too?

> module. This is because NAT allocates different IP addresses.

Sorry, I just fail to see how this can work in practice. 

> => I'm not really sure what you're asking about, please be specific.

My point is that the whole document is written as if the Mobile IPv6
module and the IKE module were only one single module or as if an
extended API existed between the two modules. It is not because 3775 has
left some undefined elements that we can base the specs on those (and
extend them). What do you think?

> => We do assume internal APIs between MIPv6 and IKE.

In that case, that should probably be stated *explicitly*. Listing the
functions/purposes of this APIs would IMHO clarify the situation (but
would still not allow interoperability between various IKE and MIPv6
implementations). In the end, I think the list will have quite some
items, and possibly some that are not so simple to handle in the real
life.

Cheers,

a+

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 10 Dec 2008 15:13:25 +1100

> ...). Don't hesitate if you think my comments make sense.

=> It's ok the chairs are on the list and they are all emails.

> s/for it MIPv6 its binding/for its MIPv6 binding/    no?

=> Sure, I was looking for something wrong with the logic and missed the
typo.

> Well, if you make IKE a requirement in DSMIPv6, you are indeed right.

=> Ok, I think it needs to be.

> specified in MIPv6 documents.

=> Yes of course.

> does it know which ones have been selected by the HA?

=> Are you still talking about the IKE daemon in the HA? It's responding to
IKE messages from the MN. I don't understand the question.
If you're talking about IKE in the MN, then it's more confusing to me
because it *initiates* the communication.

> Don't hesitate to correct me on that.

=> There is nothing to correct, but there is not much I can do about that in
DSMIP. We are using assumptions in MIPv6, so yes we know the above issues
and there are pseudo-standard APIs on some platforms for this.

> support that? What is the reason not to require that for the MN too?

=> I believe you were quoting text that refers to updates due to the MN's
address changes. It is required for the HA as the default mechanism. If the
MN supports it then it's fine, if not the MN will need to re-negotiate the
SA. So there is no need to mandate it for the MN.

> Sorry, I just fail to see how this can work in practice.

=> Ok, I'm guessing (because you didn't say) that this is related to the API
concern you have. My point on that is that it's a bit too late to worry
about it since it's already out there in implementations. It may need to be
extended to support this spec but we're not inventing a new concept.

> extend them). What do you think?

=> I think that this API was already assumed 5 years ago during the security
rehash of MIPv6. This is not a new assumption in this spec.

> items, and possibly some that are not so simple to handle in the real

=> Please see above. It's not a new concept.

Hesham

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 09 Dec 2008 21:17:13 -0800

Hi,

ok.

>> specified in MIPv6 documents.

ok, but that's just not clearly stated in the document. 

> IKE messages from the MN. I don't understand the question.

Sorry for the confusion. I wrote HA while thinking MIPv6 module: the
correct last sentence is: How does it know which one has been selected
by the MIPv6 module? 

> because it *initiates* the communication.

IKE needs to be modified to guess the right address, that's all I say. In
the same fashion as *expected* in 3775/3776 for initial transport mode
negotiation. I think you just suppose "the API" also provides that.

> and there are pseudo-standard APIs on some platforms for this.

Well, I don't expect DSMIP document to provide the API but stating
explicitly it is not defined (or that some drafts are available at
various places) would help, IMHO.

You will agree that the document adds additonal requirements for that
API, w/o making them explicit.

> SA. So there is no need to mandate it for the MN.

Let me rephrase it: Why is it a MUST on the HA (i.e. *arguments*) and some
kind of 'can' for the MN? How were those levels of support decided? Based
on which *technical* arguments?

> about it since it's already out there in implementations.

What can I say: I worked on the API (MIGRATE), made a followup draft
correcting problems found during the implementation, implemented support
for racoon, UMIP, additions for Linux Kernel and helped strongSwan
people during their implementation of my draft.

> It may need to be extended to support this spec but we're not
> inventing a new concept.

;-)

>From the discussion I had w/ Julien some time ago on the need for that
kind of API, I am not that sure. And I don't think we should issue specs
with floating assumptions. We cannot expect future implementors were
there 5 or 6 years ago reading the list, can we?

Cheers,

a+

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 10 Dec 2008 16:57:07 +1100

> ok, but that's just not clearly stated in the document.

=> I'm trying to make it clear that the document is not inventing this API
but inheriting it. In order for anyone to be able to implement this document
they need to read 3775/6, 4877 and understand the interactions with IPsec.
If people do that, then they *already* know that an API exists. For example,
did you see any reference of this API in nemo specs? Any reference in any
other MIPv6 specs that are dependent on the specs above?
There is a reason for that: they all depend on the original MIPv6 specs.

> negotiation. I think you just suppose "the API" also provides that.

=> There is no guessing in the MN, it's provided the home address as part of
the src address selection. If you're talking about running IKE for NAT
traversal and securing all traffic then it re-uses the SAs for the home
address.

> API, w/o making them explicit.

=> They are all in the security considerations discussion in great detail.
I'm not sure what you're asking us to add. Please send the text that you
think we need to add to that section.

> on which *technical* arguments?

=> Because the ideal scenario is to support this mechanism in order to
minimise traffic disruption. Therefore, we had to propose this as the
default for the HA. The mechanism itself is a SHOULD in the IKE spec.
You need to specify a default common to all MNs. Now, if an MN doesn't
support it or doesn't care then there is nothing we can do about that. There
is no point in mandating something when ignoring that mandate makes a
difference to only one side of the protocol and has no impact on the node it
communicates with.

> people during their implementation of my draft.

=> Ok, so what are you asking me to do?

> there 5 or 6 years ago reading the list, can we?

=> Of course not, but we can expect them to read the specs that we're
dependent on because they have to do that in order to implement the spec. I
personally don't want this API at all in MIPv6 but there is no point in
discussing this here. The point is this: What are you asking the WG to add
to the spec? Can you send text?

Hesham

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 09 Dec 2008 23:45:27 -0800

Hi,

Hesham Soliman <[email-masked]> writes:

> If people do that, then they *already* know that an API exists.

No. They know that there is a need for tight interactions between
IPsec/IKE and MIPv6: for bootstrapping, for tunnel endpoint updates, for
internal IKE daemon structures updates. All they get is a pointer to the
old MIGRATE draft in 4877 as a possible hint for solving the second point:

      Such address changes can be implemented, for instance, through an
      API from the Mobile IPv6 implementation to the IPsec
      implementation.  One such API is described in [12].

> For example, did you see any reference of this API in nemo specs?

No, because NEMO does not need to extend it. Does it?

> Any reference in any other MIPv6 specs that are dependent on the specs
> above? 

No, but are there some among those that extend the API?

> There is a reason for that: they all depend on the original MIPv6 specs.

Or they do not have additional needs associated w/ the API.

> traversal and securing all traffic then it re-uses the SAs for the home

Sorry, but I fail to understand the whole paragraph. What I say is the
following: when a common Mobile Node negotiates its initial transport
mode SA (for securing signaling traffic, i.e. BU/BA w/ the HA), it needs
to perform the IKE negotiation using the CoA. A common IKE
implementation is not expected to do that (SP uses the HoA, which is
not available at that time) and need to be modified to support that. One
possible solution is to have the right address (CoA) provided to the IKE
daemon by the MIPv6 module. Obviously, you are aware of that. Now what
are the exact steps on a DSMIPv6-compliant MN using IKE when it starts
operating in an IPv4-only network? I just reread 6.2.1 and it still
seems unclear to me how the IKE implementation will decide that it
should use a V4ADDR and then which V4ADDR it will use.

Does the IKE implementation take the first v4 address available to do
that? What if it has multiple interfaces with privates IPv4 address?

It is possible I missed some part in the document that explain that
precisely.

> => They are all in the security considerations discussion in great detail.

Some of my comments/questions were about those elements of the security
consideration section. 

> think we need to add to that section.

ok. I will *try* and find some time this WE to provide some text.

> difference to only one side of the protocol and has no impact on the node it

It does not seem logical to me. Sorry. It just creates a situation where
client will undergo traffic disruption with a compliant implementation
even if the one on the HA support the feature. 

> => Ok, so what are you asking me to do?

I don't know. What about taking a look at the draft [1] and see if the
API can easily be used/extended for some of the needs you have in the
doc. I let you decide.

[1]: http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00

> dependent on because they have to do that in order to implement the
> spec.

yes, I agree.

> I personally don't want this API at all in MIPv6 but there is no point in
> discussing this here.

I don't think this would make sense to add the API in MIPv6 either. But
support for IPsec tunnel endpoints update upon movement is required by
3775. Bootstrapping w/ IKE does not work w/o it and updates of internal
IKE structures is also a need. In the end, for things to work smoothly,
it is needed.

> The point is this: What are you asking the WG to add to the spec? Can
> you send text? 

As written previously, I will try and take a look this WE, and then send
some text.

Cheers,

a+

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 11 Dec 2008 14:29:01 +1100

>       implementation.  One such API is described in [12].

=> That's right, and I think that's all that can be done in standards if we
need internal APIs. The IETF typically doesn't standardise APIs, with the
except of the pseudo standard socket API.

> Or they do not have additional needs associated w/ the API.

=> Ok, so I gather from these comments that you're only concerned about
clearly identifying the extensions. So if you can go through the security
section and let us know if any of the extensions are not clear that would be
helpful.

> It is possible I missed some part in the document that explain that

=> You didn't miss it, it's not in the draft. The issue of the "right" CoA
is a policy issue that needs to be addressed by src address selection. If
the MN is multihomed then there must be a number of factors involved in
making this decision, none of them can be attributed to DSMIPv6. Of course
once an SA is established, then that information needs to be passed to MIPv6
in order choose the right CoA. The initial choice between a number of CoAs
is basically irrelevant to DSMIPv6. Do you think DSMIPv6 needs to specify
which CoA should be chosen and how? I don't think that would fit into the
scope of the spec.

You can make the same argument about a multihomed IPv6 MN and reach the same
conclusion, no?

> even if the one on the HA support the feature.

=> Yes of course but that can always happen for many features in MIPv6. It
makes no sense to mandate something that, when not followed, has no impact
on interoperability. We need to mandate the support in the HA, so MN's can
assume a certain level of support and therefore interoperable
implementations. If the HA initiated the requests we would have mandated the
support in the MN.

> [1]: http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00

=> I'm happy to discuss that with you in a separate thread, but I fail to
see how this will improve the quality of DSMIPv6, which is our highest
priority now. I.e., if, for whatever reason, the changes needed don't fit
into your draft, that will not give me any indication as to how to improve
DSMIPv6. 

Hesham

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 17 Dec 2008 23:07:29 -0800

Hi Hesham,

Sorry for the late reply. Some additional comments below and then some
text proposals for the draft (w/ a question).

> except of the pseudo standard socket API.

which includes PF_KEY but I basically agree w/ you.

> section and let us know if any of the extensions are not clear that would be

that would be possible if we had an initial *defined* set of extensions
and a specific API. At best, RFC 3775 introduce the need for an API
between MIPv6, IKE and the IPsec stack. See my small proposal
below. It's probably not perfect but at least this make clear that
*work* is required and that it is left as an implementation issue.

> making this decision, none of them can be attributed to DSMIPv6.

Well, the MIPv6 module is usually expected to be the one selecting the
CoA so I respectfully disagree w/ you on that point. Once a CoA has been
selected (based on some preferences, policies, connectivity price,
capabilities, ...), I think failing to let the small number of apps
(IKE for instance) that need to use that CoA instead of the HoA is just
leaving room for trouble.

> Of course once an SA is established, then that information needs to be
> passed to MIPv6 in order choose the right CoA.

The CoA is selected by the MIPv6 module, before SA are
negotiated. Basically, this is the first BU which triggers the
negotiation of the SA. IKE has nothing to do with CoA selection. It is
just there to negotiate the protection. 

> The initial choice between a number of CoAs is basically irrelevant to
> DSMIPv6.

Well, considering what is in section 5.4 of the draft, and more
precisely in 5.4.1 ("Selecting a Care-of address"), I disagree.

> Do you think DSMIPv6 needs to specify which CoA should be chosen

It does, when there are IPv6 and IPv4 addresses available.

> and how? I don't think that would fit into the scope of the spec.

I don't know. Maybe this is a local matter (based on various policies)
but that local matter may become a problem if there is no sync between
IKE and MIPv6.

Coming back to IKE, MIPv6 is expected to do that for IKE. The problem
is introduced in section 1 of RFC 3776:

   Great care is needed when using IKE [4] to establish security
   associations to Mobile IPv6 home agents.  The right kind of addresses
   must be used for transporting IKE.  This is necessary to avoid
   circular dependencies in which the use of a Binding Update triggers
   the need for an IKE exchange that cannot complete prior to the
   Binding Update having been completed.

And later section 5.3.1 of RFC3776 for the negotiation of the SA
protecting BU/BA contains this: 

   We require IKE version 1 to be run using the care-of addresses but
   still negotiate IPsec SAs that use home addresses.

Section 4.4 contains:

   o  In addition to the rules above, if dynamic keying is used, the key
      management protocol MUST use the care-of address as the source
      address in the protocol exchanges with the mobile node's home
      agent.

Those are also in RFC 4877.

> You can make the same argument about a multihomed IPv6 MN and reach
> the same conclusion, no?

Yes. Exactly.

> implementations. If the HA initiated the requests we would have mandated the

Still not convinced, but if I am the only one complaining, I will stop
arguing on that.

> into your draft, that will not give me any indication as to how to improve

ack.

Below is the text proposals for the draft (based on version 07):

>    This specification requires the use of IKEv2 as the default mechanism
>    for dynamic keying.

Maybe it is just my english but, it reads: "when dynamic keying is used,
IKEv2 MUST be used". From previous discussions, I thought the level of
requirement to be different and read "DSMIPv6 implementations are
required to use IPsec with dynamic keying using IKEv2". 

>    using ESP transport mode.  When the mobile node is located in an
>    Handovers within private IPv4 networks or from IPv6 to IPv4 networks
>    will have impacts on the security association between the mobile node
>    and the home agent.  The following section presents the expected
>    behaviour of the mobile node and home agent in those situations.  The
>    details of the IKE negotiations and messages are illustrated in
>    Section 6.2
> 
>    number. The home agent may also need to change NAT traversal fields
>    authenticated packets using tunnel mode ESP.  The dynamic updates are
>    described in section 2.23 of RFC 4306. As described above, when the
>    SHOULD send an empty informational message, which results in the IKE
>    feature.  Alternatively, the IKE SA should be re-negotiated.  Note

What about inserting the following text here ?:

"Note that providing the features described in this subsection is
 expected to require very tight interactions between MIPv6 and IKE. It
 may require substantial extensions of the API expected by [RFC3775] to
 be in place between the MIPv6 module, the IPsec stack and the IKE
 daemon. This possible extensions (and the expected level of
 interactions with the features provided by the IKE module) are outside
 the scope of this specification and are left as implementation
 dependent issues."

Note that I first inserted small disclaimers w/ specific comments at
various places in the subsection but this made the whole thing more
difficult to read w/o providing any additional interest. I dropped that
for a single more generic block.

If you think previous text proposal should be extended in some way, just
tell me.

Cheers,

a+