Subject: [MEXT] Review of draft-ietf-mext-nemo-pd-04

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 6 Apr 2010 09:59:44 -0700

<chair hat off>

I have reviewed the document -- please see below the comments that I'd like to see resolved.

--julien

---------------------------------------------------------------------------

Section 2:
----------

[...]

   The following terms used in this document are defined in the IPv6
   Addressing Architecture document [RFC4291]:

      link-local unicast address

      link-local scope multicast address

   The following terms used in this document are defined in the mobile
   IPv6 specification [RFC3775]:

      home agent (HA)

      home link

I suggest that the terms above to Capitalize the Link-Local Unicast, Link-Local Scope Multicast, Home Agent, and Home Link.

Section 3:
----------

3.  Application of DHCPv6 prefix delegation to mobile networks for
    delegation of home prefixes

That's kind of long for a section title. How about "DHCPv6 Prefix Delegation of Home Prefixes"

   To use DHCPv6PD for Mobile Networks, the HA assumes the role of
   either the DR or a DHCPv6 relay agent and the MR assumes the role of
   the RR.  Throughout the remainder of this document, the HA will be
   assumed to be acting as a DHCPv6PD DR or relay agent and the MR will
   be assumed to be acting as a RR.

   If the HA is acting as relay agent, some other device acts as the DR.
   For example, the server providing DHCPv6 service in the home network
   might also provide NEMO DHCPv6PD service.  Or, a home network with
   several HAs might configure one of those HAs as a DHCPv6PD server
   while the other HAs act as relay agents.

I don't think we should allow for the HA to be relay. The HA should be the delegating router. There are multiple reasons for this:

1) the HA is a router so it can perfectly be the delegating router.

2) the HA is stateful with respect to mobile routers because it is managing binding cache entries, thus making the DHCP component in the HA a stateless DHCP relay doesn't save us anything in terms of the requirement to maintain state.

3) If the HA were a DHCP relay, there would be no way for the HA to enforce that the MR is registering the prefix that was delegated to him via DHCP PD as mandated per RFC 3963:

   If the Mobile Router sends a Binding Update with a one or more Mobile
   Network Prefix options, the Home Agent MUST be able to verify that
   the Mobile Router is authorized for the prefixes before setting up
   forwarding for the prefixes.

... because the DHCP relay is stateless and does not keep track of the prefixes delegated. Thus enforcing the above provision of RFC 3963 would require either of A) have the DHCP relay parse the DHCP messages it relays and keep track of the prefixes, or B) have an out-of-band protocol between the HA and the delegating router, none of which is acceptable. If we do A) then the relay is stateful and no longer a relay but rather some sort of unspecified DHCP proxy. If we do B) we have an incomplete solution with an increased system complexity for no added value.

   The HA and MR exchange DHCPv6PD protocol messages through the tunnel
   connecting them (as specified in RFC3775).  The tunnel acts as the
   link labeled "DSL to subscriber premises" in figure 1 of the DHCPv6PD
   specification.  See Figure 1 for different possible deployment
   topologies.

For the HA and MR to exchange messages through the tunnel there needs to be a DHCP relay collocated within the MR -- otherwise the MR will first send a message sourced from and destined to link-local addresses that will not be forwarded in the tunnel. This as implication on the following figure:

         ----      /-----------\      ----
        | MR |-----|  Internet |-----| HA |
        |(RR)|     \-----------/     |(DR)|
         ----                         ----
This is only applicable when the MR is on the home link because, as acknowledged in the previous paragraph, the HA and MR exchange messages in the tunnel. Since the source address of the first DHCP message sent will be a link-local unicast and the destination address a link-local scope multicast address, the message will not make it into the tunnel.

         ----      /-----------\      -----       ------
        | MR |-----|  Internet |-----| HA  |-----|DHCPv6|
        |(RR)|     \-----------/     |(DRA)|     |Server|
         ----                         -----       ------

As discussed above, I believe this should be removed as having the HA acting as a relay increases the system complexity for no benefit.

         -----     /-----------\      -----
        | MR  |----|  Internet |-----| HA  |
        |(RR) |    \-----------/     |(DR) |
        |(DRA)|                       -----
         -----

This accurately represent the setup when the Mobile Router is away from home. I think it would be clearer if we split this figure in two, one for the at home case (no DRA in MR), one for the away from home case (DRA in MR.)

   Figure 1: Different topologies of the application of DHCPv6PD to NEMO
                          for delegation of MNPs

[...]

Section 3.1
------------

3.1.  When the MR uses DHCPv6

   The MR initiates a DHCPv6 message exchange for prefix delegation
   whenever it establishes an MR-HA tunnel to its HA.

I think we should say that the MR initiates a DHCPv6 message exchange for prefix delegation whenever it needs to acquire the prefix it is delegated with. This is not necessarily coupled with establishment of the MR-HA tunnel, as the Mobile Router might need to acquire such prefixes while on the home link.

When the MR is at home, the relay agent in the MR is deactivated. When the MR is away from home, the relay agent in the MR is activated and the DHCP message exchange is carried in the tunnel, which implies that the MR-HA tunnel has been established before. The MR determines whether it is at home based on Home Link Detection as explained in section 11.5.2 of RFC 3775bis:

<http://tools.ietf.org/html/draft-ietf-mext-rfc3775bis-05#section-11.5.2>

                                                        If the MR does
   not have any active delegated prefixes (with unexpired leases), the
   MR initiates a DHCPv6 message exchange with a DHCPv6 Solicit message
   as described in section 17 of RFC 3315 and section 12.1 of RFC 3633.
   Once the MR has been delegated a set of prefixes from the HA, the MR
   sends a new Binding Update including the delegated prefixes, carried
   in Mobile Network Prefix options (see Figure 2). Note that this
   requires a minor modification to the NEMO Basic Support protocol as
   described in RFC 3963.  RFC 3963 does not assume the MR can change
   from implicit to explicit BU signaling mode, while this specification
   requires the MR to first perform a MIPv6 registration to the HA
   providing DHCPv6PD services (via implicit signaling, no MNP carried
   in the BU), then obtain a set of delegated prefixes via DHCPv6PD, and
   then send a new BU to the Home Agent, now carrying the delegated
   prefixes as Mobile Network Prefixes (explicit signaling mode).

I believe we should always operate in implicit mode when DHCPv6 PD is used together with NEMO, as it fits perfectly with the definition in the NEMO specification [RFC3963], satisfy the security requirements I outlined earlier, does not require to send two binding updates and to switch between two modes (Implicit/Explicit) which is not mandated by the NEMO specification as quoted below:

      Implicit:

         In this mode, the Mobile Router does not include a Mobile
         Network Prefix Option in the Binding Update.  The Home Agent
         can use any mechanism (not defined in this document) to
         determine the Mobile Network Prefix(es) owned by the Mobile
         Router and to set up forwarding for the Mobile Network.  One
         example would be manual configuration at the Home Agent mapping
         the Mobile Router's Home Address to the information required
         for setting up forwarding for the Mobile Network.

      Explicit:

         In this mode, the Mobile Router includes one or more Mobile
         Network Prefix Options in the Binding Update.  These options
         contain information about the Mobile Network Prefix(es)
         configured on the Mobile Network.

   A Mobile Router MUST implement at least one mode and MAY implement
   both.  In the latter case, local configuration on the Mobile Router
   decides which mode to use.  This is out of scope for this document.

So clearly were we to require switching between two modes we would be placing an additional requirement on a NEMO implementation. We'd better off placing the requirement that implicit mode is required for the reasons I outlined above.

   In case the MR has one or more active delegated prefixes, the MR
   initiates a DHCPv6 message exchange with a DHCPv6 Rebind message as
   described in section 18.1.2 of RFC 3315 and section 12.1 of RFC 3633.
   In this case, only one BU signaling sequence is required.

Single BU signaling sequence should be the default, and that's achievable by making implicit mode the default mode of operation of NEMO while using it together with DHCP prefix delegation.

[...]

Section 3.2
------------

3.2.  Use of MR-HA tunnel for DHCPv6 messages

   The DHCPv6 specification requires the use of link-local unicast and
   link-local scope multicast addresses in DHCPv6 messages (except in
   certain cases as defined in section 22.12 of the DHCPv6
   specification).  Section 10.4.2 of the mobile IPv6 specification
   describes forwarding of intercepted packets, and the third paragraph
   of that section begins:

      However, packets addressed to the mobile node's link-local address
      MUST NOT be tunneled to the mobile node.

   The DHCPv6 messages exchanged between the HA and the MR originate
   only with the HA and the MR, and therefore are not "intercepted
   packets" (i.e. the sender of the packets is a third node on the home
   link) and may be sent between the HA and the MR through the tunnel.

   Even though the MR-HA tunnel is a point to point connection, the MR
   SHOULD use multicast DHCPv6 messages as described in RFC 3315 over
   that tunnel.

Citing Section 10.4.2 of RFC 3775 is a good idea, but we're missing the first paragraph of that section that states:

   For any packet sent to a mobile node from the mobile node's home
   agent (in which the home agent is the original sender of the packet),
   the home agent is operating as a correspondent node of the mobile
   node for this packet and the procedures described in Section 9.3.2
   apply.  The home agent then uses a routing header to route the packet
   to the mobile node by way of the primary care-of address in the home
   agent's Binding Cache.

Thus, according to RFC 3775, the DHCPv6 messages sent from the HA to the MN would be sent with a routing header to the care-of address, the destination address being a link-local address because that's the address the DHCPv6 client on the MN initiated the exchange with.

The provision above, taken together with the last MUST in the paragraph of Section 6.4 "Type 2 Routing Header" quoted below, would prevent the HA from sending the said locally generated DHCPv6 message to the MN's link-local address:

   The new routing header uses a different type than defined for
   "regular" IPv6 source routing, enabling firewalls to apply different
   rules to source routed packets than to Mobile IPv6.  This routing
   header type (type 2) is restricted to carry only one IPv6 address.
   All IPv6 nodes which process this routing header MUST verify that the
   address contained within is the node's own home address in order to
   prevent packets from being forwarded outside the node.  The IP
   address contained in the routing header, since it is the mobile
   node's home address, MUST be a unicast routable address.
   Furthermore, if the scope of the home address is smaller than the
   scope of the care-of address, the mobile node MUST discard the packet

So I believe what's described in this section does not work. Rather, I believe that what some of us originally had in mind is that the DHCPv6 messages exchanged between the MR and the RA are exchanged between the DHCP relay agent on the MR and the DHCP server on the HA, as described in the next section 3.2., and those messages are carried inside the MR-HA tunnel, i.e., the MR sends packets from the global unicast HoA to the global unicast HA address, and vice versa.

Section 3.3.
-------------

3.3.  DHCPv6 Relay Agent for transmission of DHCPv6 messages

   A DHPCv6 relay agent function [RFC3315] can be used as an alternative
   to multicast DHCPv6 messages over the tunnel between the MR and the
   HA.  In this configuration, the relay agent function is co-located in
   the MR with the DHCPv6 client function (see Figure 3.  Rather than
   using multicast to send DHCPv6 messages through the tunnel to the
   DHCPv6 server, the DHCPv6 client in the MR hands any outbound DHCPv6
   messages to the co-located relay agent.  Responses from the DHCPv6
   server are delivered to the relay agent function in the MR, which
   extracts the encapsulated message and delivers it to the DHCPv6
   client in the MR.

As I commented in section 3.2., the use of the DHCPv6 relay agent is not exclusive to sending message of the tunnel but should be used together with it.

[...]

Section 3.3.1
--------------

3.3.1.  Relay agent configuration

   The use of the relay agent function in the MR allows the MR to
   unicast DHCPv6 messages to the DHCPv6 server.  The relay agent must
   be configured with the address of the DHCPv6 server or another DHCPv6
   relay agent that will forward message on to a DHCPv6 server.  For the
   purposes of NEMO, the relay agent assumes that the HA for the MR
   hosts the next hop in the path the to the DHCPv6 server: either the
                                  ^^^

s/the/to the/

   DHCPv6 server or a relay agent that will forward message to the
   DHCPv6 server.  Therefore, if the MR acts as a DHCPv6 relay agent,
   the MR MUST configure the DHCPv6 relay agent to forward DHCPv6
   messages to the HA.

As I said earlier I do not think that having the HA acts as a relay agent is a practical configuration. Thus, this section could simply states that the relay agent in the MR is configured with the address of the HA that acts as a DHCP server. (The address of which can be retrieved via an interface to the MIPv6/NEMO agent on the MR)

Section 3.4
-----------

3.4.  Exchanging DHCPv6 messages when MR is at home

   When the MR is on its home link, the HA uses the home link to
   exchange DHCPv6PD messages with the MR.  It is the responsibility of
   the implementation to determine when the MR is on its home link and
   to avoid use of any existing tunnel.

I think we should point to the Home Link Detection detailed in section 11.5.2 of RFC 3775bis:

<http://tools.ietf.org/html/draft-ietf-mext-rfc3775bis-05#section-11.5.2>

Section 3.5
-----------

3.5.  Selecting an HA that provides DHCPv6PD

   Not all nodes that are willing to act as an HA are required to
   provide DHCPv6PD.  Therefore, when selecting an HA, an MR that
   requires DHCPv6PD service must identify an HA that will provide the
   service.  The MR can determine if an HA provides DHCPv6PD by
   initiating a DHCPv6 message exchange in which the MR requests
   delegated prefix(es).  If the HA does not respond or responds but
   does not delegate any prefix(es) in its response, the MR assumes that
   the HA does not provide DHCPv6PD service.  The MR continues to query
   all candidate HAs until it finds an HA that provides DHCPv6PD.  Note
   that in this particular case, the MR has also to setup a tunnel with
   each HA (this requires the MR to perform an MIPv6 registration) it
   queries.

As commented earlier, setting up a tunnel is only necessary when away from home. While on the home link, no tunnel is necessary.

Section 3.7.
------------

3.7.  Location of DHCPv6PD Delegating Router function

   Support of DHCPv6PD for a Mobile Network is optional.

Stating in RFC-to-be XXXX describing feature Z that support for feature Z is optional is IMHO convoluted and unnecessary. I suggest we remove the above.

   The use of a DHCPv6 relay agent in DHCPv6PD may require "a protocol
   or other out-of-band communication to add routing information for
   delegated prefixes into the provider edge router" (section 14 of RFC
   3633).  If the DHCPv6PD DR function is implemented in the HA for the
   MR, no relay agent function is required.

Exactly, hence my wish that we simply remove the possibility for the HA to be a relay agent, as I explained before it does not allow the HA to be stateless anyway, and requires out-of-band signaling that we do not know about thus making the solution incomplete.

   It may be desirable to use a single DR to manage RRs in a network
   with multiple HAs.  In this scenario, the HAs will act as DHCP relay
   agents, forwarding messages between the RRs and the DR.

I disagree that this is desirable. I actually find it undesirable.

   The use of the DHCPv6 relay agent function with DHCPv6PD requires
   that there be some mechanism through which routing information for
   the delegated prefixes can be added to the appropriate routing
   infrastructure.  If the HA is acting as a DHCPv6 relay agent, the HA
   SHOULD add a route to the delegated prefix and advertise that route
   after receiving a binding update for the prefix from the RR
   [RFC3963].

I do not understand why having the HA advertising a route to the delegated prefix is conditioned by the HA acting as a DHCPv6 relay agent. To me these seems to be orthogonal. It seems to me that having the HA advertising a route to the delegated prefix is conditioned by the delegated prefix being aggregated entirely under a Home Agent acting as the sole default router on the Home Link, and I think is adequately covered in RFC 3963. I don't see what we need to add. And again we should not allow for the HA to be a relay agent.

   In particular, if the MR uses NEMO explicit mode, then it must add
   the delegated prefix to the prefix list in the Binding Update
   messages.  If the binding cache is cleared before the prefix valid
   lifetime, the MR might bind that prefix again using explicit mode,
   till the lifetime expires.

Besides the fact that I think we should limit ourselves to implicit mode operation while doing NEMO prefix delegation, I think the above is already covered in RFC 3963 and thus can be removed from the draft.

[...]

   At the time this document was written, one way in which a DR can
   explicitly notify a relay agent about delegated prefixes, is to use
   the "DHCP Relay Agent Assignment Notification Option"
   [I-D.ietf-dhc-dhcpv6-agentopt-delegate].

   Another alternative, if the RR is part of the same administrative
   domain as the home network to which it is attached through the HA,
   and the RR can be trusted, the RR can use a routing protocol like
   OSPF to advertise any delegated prefixes.

   NEMO explicit mode is recommended to take advantage of the function
   already defined for NEMO.

I disagree with the recommendation and think we should always use implicit mode together with DHCPv6 PD. But besides that, what does "to take advantage of the function already defined for NEMO" means? What are the advantages? I only see drawbacks (need for an out-of-band protocol + security issues.)

Section 4.
----------

4.  Security Considerations

   This document describes the use of DHCPv6 for prefix delegation in
   Mobile Networks.  It does not introduce any additional security
   considerations for DHCPv6 beyond those described in the "Security
   Considerations" section of the DHCPv6 base specification [RFC3315]
   and the "Security Considerations" of the DHCPv6 Prefix Delegation
   specification [RFC3633].

As I have commented earlier I believe that this is factually incorrect since the NEMO base specification requires the HA to enforce that the MR is registering the prefix that was delegated to him via DHCP PD. This should be outlined in this section.

   The use of DHCPv6, as described in this document, requires only
   message integrity protection, which can be provided by the mobile
   network infrastructure between the MR and the HA.

See my comment above -- I disagree with the "only" requirement being message integrity.

I also find the statement above on integrity protection being provided by the mobile network infrastructure as vague. What is the mobile network infrastructure? Is it the IPsec Security Associations that are present between the MR and HA.

As a result I find this statement not only useless but harmful given that we're in the security considerations section. I think we should either be explicit in terms of what sort of integrity protection is provided and by which mechanism, or remove that statement altogether.

If we're referring to IPsec between the HA and the MR, then we should also explicitly list the SPD and SAD entries that allow protection of the tunneled DHCPv6 messages, as data plane protection is an optional feature of IPsec support for MIPv6 and thus NEMO.

   If the network infrastructure connecting the various communicating
   nodes does not provide message integrity and source authentication
   for the DHCPv6PD messages, HAs and MRs SHOULD use DHCPv6
   authentication as described in section "Authentication of DHCP
   messages" of the DHCPv6 specification [RFC3315], to guard against
   attacks mounted through prefix delegation.

I think we need not to recommend DHCPv6 authentication as a protection mechanism in the context of NEMO. The use of NEMO already requires IPsec Security Associations between the HA and the MR. I see no reason why we should not leverage on these...

   If the HA and DHCPv6 PD functions are not provided by the same
   physical node, the HA will act as a DHCPv6 relay agent between the MR
   and the DHCPv6 server.

We should remove this scenario for the reasons I've outlined earlier, making the rest of the section unnecessary.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sun, 11 Apr 2010 19:24:33 +0200

Dear Julien,

Thanks a lot for your review. Please see some comments inline below.

> I have reviewed the document -- please see below the comments that I'd like to see resolved.

OK.

> Section 3:

Agree, what about the following (minor modification of your proposal):
"DHCPv6 Prefix Delegation of Mobile Network Prefixes"?

> ... because the DHCP relay is stateless and does not keep track of the prefixes delegated. Thus enforcing the above provision of RFC 3963 would require either of A) have the DHCP relay parse the DH…

I agree on what you say, but I think there is still value on allowing
additional approaches for NEMO-PD. If people implementing it do not
consider the "HA behaving as DHCPv6 really" useful/needed for a
particular use case, this would still be fine. It is not mandated to
support all configuration options.

> For the HA and MR to exchange messages through the tunnel there needs
> to be a DHCP relay collocated within the MR -- otherwise the MR will
> first send a message sourced from and destined to link-local addresses
> that will not be forwarded in the tunnel. This as implication on the

I'm gonna send a separate e-mail to discuss the issue of the link-local
unicast/multicast tunneling.

>  following figure:
> This accurately represent the setup when the Mobile Router is away
> from home. I think it would be clearer if we split this figure in two,
> one for the at home case (no DRA in MR), one for the away from home
> case (DRA in MR.)

OK, I'll split the figures. I'll do it once all the issues related to
the setups that are possible/considered in the draft are cleared.

>    Figure 1: Different topologies of the application of DHCPv6PD to NEMO

I agree we need to take the MR-at-home scenario. It might be just easier
to add a section for that and then let the rest of the sections deal
with the MR-not-at-home scenarios, which are the ones that probably
deserve more explanation (when the MR is at home, there is not much else
to say, since plain DHCPv6PD could be used there).

> 
> When the MR is at home, the relay agent in the MR is deactivated. When
> the MR is away from home, the relay agent in the MR is activated and
> the DHCP message exchange is carried in the tunnel, which implies that
> the MR-HA tunnel has been established before. The MR determines
> whether it is at home based on Home Link Detection as explained in
> section 11.5.2 of RFC 3775bis:
> 
> I believe we should always operate in implicit mode when DHCPv6 PD is
> used together with NEMO, as it fits perfectly with the definition in
> the NEMO specification [RFC3963], satisfy the security requirements I
> outlined earlier, does not require to send two binding updates and to
> switch between two modes (Implicit/Explicit) which is not mandated by
> the NEMO specification as quoted below:
> 
>       Implicit:
> 
> So clearly were we to require switching between two modes we would be
> placing an additional requirement on a NEMO implementation. We'd
> better off placing the requirement that implicit mode is required for
> the reasons I outlined above.
> 

I think your approach does not comply with RFC 3963 either. Note that I
say either, because after a careful reading of RFC 3963 I think current
one does not really do either. Let me explain, just to check if I'm
missing something.

RFC 3963 says the following (Section 6.2 Mobile Network Prefix
Registration):

"[...] the Home Agent
   retrieves the Mobile Network Prefix information as described below.

-  If there is no option in the Binding Update carrying prefix
      information, the Home Agent uses manual pre-configured information
      to determine the prefixes assigned to the Mobile Router and to set
      up forwarding for the Mobile Network.  If there is no information
      that the Home Agent can use, it MUST reject the Binding Update and
      send a Binding Acknowledgement with status set to 143 (Forwarding
      Setup failed)."

With your approach, the MR would send a BU with no MNP options (implicit
mode), set-up the tunnel and then send the DHCPv6 signalling to obtain
the prefixes. However, the HA would fail to setup the binding and
tunnel, since it has no information to determine the prefixes assigned
to the Mobile Router (the DHCPv6 signalling has not yet taken place).

With current approach of the draft (-04), a similar problem will arise,
since the first BU sent by the MR to establish the tunnel would also
fail, since there is no MNP in the BU (implicit mode) and the HA does
not know either the prefixes assigned to the MR.

The only way of this to work is to assume that the HA is allowed to set
up the forwarding of the prefixes that would be later on delegated to
the MR. I don't know if this breaks RFC 3963. If not and this behaviour
is possible, then both approaches would be valid.

> Single BU signaling sequence should be the default, and that's
> achievable by making implicit mode the default mode of operation of
> NEMO while using it together with DHCP prefix delegation.
> 
> [...]
> 
> Section 3.2
> ------------
> 
> Citing Section 10.4.2 of RFC 3775 is a good idea, but we're missing
> the first paragraph of that section that states:
> 
> Thus, according to RFC 3775, the DHCPv6 messages sent from the HA to
> the MN would be sent with a routing header to the care-of address, the
> destination address being a link-local address because that's the
> address the DHCPv6 client on the MN initiated the exchange with.
> 
> The provision above, taken together with the last MUST in the
> paragraph of Section 6.4 "Type 2 Routing Header" quoted below, would
> prevent the HA from sending the said locally generated DHCPv6 message
> to the MN's link-local address:
> 
> So I believe what's described in this section does not work. Rather, I

I'll send a separate e-mail to address this.

>  believe that what some of us originally had in mind is that the
> DHCPv6 messages exchanged between the MR and the RA are exchanged
> between the DHCP relay agent on the MR and the DHCP server on the HA,
> as described in the next section 3.2., and those messages are carried
> inside the MR-HA tunnel, i.e., the MR sends packets from the global
> unicast HoA to the global unicast HA address, and vice versa.
> 
> Section 3.3.
> -------------
> 
> As I commented in section 3.2., the use of the DHCPv6 relay agent is
> not exclusive to sending message of the tunnel but should be used
> together with it.
> 
> [...]
> 
> Section 3.3.1
> --------------
> 

Fixed, Alex also pointed it out. Thanks.

> As I said earlier I do not think that having the HA acts as a relay
> agent is a practical configuration. Thus, this section could simply
> states that the relay agent in the MR is configured with the address
> of the HA that acts as a DHCP server. (The address of which can be
> retrieved via an interface to the MIPv6/NEMO agent on the MR)

I'll wait until we clear the previous issue to address this comment.

> Section 3.4

OK, I can add a reference there. BTW, I think we should update
references to RFC 3775 and point them to draft-ietf-mext-rfc3775bis
instead.

> As commented earlier, setting up a tunnel is only necessary when away
> from home. While on the home link, no tunnel is necessary.

OK, I've updated the text to make that explicit.

> Section 3.7.

I guess the idea was to highlight that NEMO-PD is not a mandatory
component of NEMO Basic Support, but if people agree we don't need that
piece of text, I'd remove it.

> Exactly, hence my wish that we simply remove the possibility for the
> HA to be a relay agent, as I explained before it does not allow the HA
> to be stateless anyway, and requires out-of-band signaling that we do
> not know about thus making the solution incomplete.
> 

Since it's related to something previously discussed in this e-mail, I
don't comment further on this here.

> I do not understand why having the HA advertising a route to the
> delegated prefix is conditioned by the HA acting as a DHCPv6 relay
> agent. To me these seems to be orthogonal. It seems to me that having
> the HA advertising a route to the delegated prefix is conditioned by
> the delegated prefix being aggregated entirely under a Home Agent
> acting as the sole default router on the Home Link, and I think is
> adequately covered in RFC 3963. I don't see what we need to add. And
> again we should not allow for the HA to be a relay agent.

I think the idea behind that piece of text is that the HA does not
advertise Mobile Network Reachability for a prefix delegated through
DHCPv6 until there is an active binding for the MR (or the MR is at
home). If the HA is not the only router on the Home Link this would be
needed.

> Besides the fact that I think we should limit ourselves to implicit
> mode operation while doing NEMO prefix delegation, I think the above
> is already covered in RFC 3963 and thus can be removed from the draft.

Let's wait until we clear the related issue on implicit mode operation.

> I disagree with the recommendation and think we should always use
> implicit mode together with DHCPv6 PD. But besides that, what does "to
> take advantage of the function already defined for NEMO" means? What
> are the advantages? I only see drawbacks (need for an out-of-band
> protocol + security issues.)

I commented on this when addressing Michaela's comments.

> As I have commented earlier I believe that this is factually incorrect
> since the NEMO base specification requires the HA to enforce that the
> MR is registering the prefix that was delegated to him via DHCP PD.
> This should be outlined in this section.

Agree on this. We need to add text on this (enforcement of MR
registering prefixes that have been obtained via DHCPv6PD) in the draft.

> I also find the statement above on integrity protection being provided
> by the mobile network infrastructure as vague. What is the mobile
> network infrastructure? Is it the IPsec Security Associations that are

The mobile network infrastructure refers to the network between the MR
and the HA. This might be protected with IPsec (protecting data packets
is not mandatory in RFC 3963).

>  present between the MR and HA.
> 
> As a result I find this statement not only useless but harmful given
> that we're in the security considerations section. I think we should
> either be explicit in terms of what sort of integrity protection is
> provided and by which mechanism, or remove that statement altogether.
> 
> If we're referring to IPsec between the HA and the MR, then we should
> also explicitly list the SPD and SAD entries that allow protection of
> the tunneled DHCPv6 messages, as data plane protection is an optional
> feature of IPsec support for MIPv6 and thus NEMO.

Right, that's why the draft says that if message integrity and source
authentication is provided in the MR-HA path (i.e. use of IPsec for data
plane protection in NEMO) then nothing else is needed. If not, then
DHCPv6 authentication as described in section "Authentication of DHCP
messages" of the DHCPv6 specification [RFC3315] should be used.

> I think we need not to recommend DHCPv6 authentication as a protection
> mechanism in the context of NEMO. The use of NEMO already requires
> IPsec Security Associations between the HA and the MR. I see no reason
> why we should not leverage on these...

We don't recommend any, we just explain the two options that are
possible.

Thanks for the comments.

Carlos

> We should remove this scenario for the reasons I've outlined earlier,
> making the rest of the section unnecessary.
> 

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 13 Apr 2010 17:49:27 -0700

Hello Carlos,

Thank you for replying to my long review.

With the intent to make this easier to follow I'm going to cut through all the parts where I agree with your proposal and only keep in the parts where more discussion is necessary. I have also taken the use of the MR-HA tunnel out of that discussion since you spawned out another thread.

[...]

> "DHCPv6 Prefix Delegation of Mobile Network Prefixes"?

Ok.

> > I don't think we should allow for the HA to be relay. The HA should
> be the delegating router. There are multiple reasons for this:
> >
> > 2) the HA is stateful with respect to mobile routers because it is
> managing binding cache entries, thus making the DHCP component in the
> HA a stateless DHCP relay doesn't save us anything in terms of the
> requirement to maintain state.
> >
> > 3) If the HA were a DHCP relay, there would be no way for the HA to
> enforce that the MR is registering the prefix that was delegated to him
> via DHCP PD as mandated per RFC 3963:
> >
> > ... because the DHCP relay is stateless and does not keep track of
> the prefixes delegated. Thus enforcing the above provision of RFC 3963
> would require either of A) have the DHCP relay parse the DHCP messages
> it relays and keep track of the prefixes, or B) have an out-of-band
> protocol between the HA and the delegating router, none of which is
> acceptable. If we do A) then the relay is stateful and no longer a
> relay but rather some sort of unspecified DHCP proxy. If we do B) we
> have an incomplete solution with an increased system complexity for no
> added value.
>

Configuration options are not a goal per se, and are often detrimental to inter-operability and overall system simplicity.

If we can provide the necessary function (i.e., delegating a prefix to a router) in a single way without options, why shouldn't we be doing that?

When the prefix is dynamically allocated by the network, what's the value of having the MR re-sending that prefix back to the network in a BU? What would be missing in restricting operation of NEMO + PD to implicit mode?

[...]

> >    both.  In the latter case, local configuration on the Mobile
> >    Router decides which mode to use.  This is out of scope for this document.
> >
> With your approach, the MR would send a BU with no MNP options
> (implicit mode), set-up the tunnel and then send the DHCPv6 signalling
> to obtain the prefixes. However, the HA would fail to setup the binding
> and tunnel, since it has no information to determine the prefixes
> assigned to the Mobile Router (the DHCPv6 signalling has not yet taken
> place).

A prefix can be allocated to the MR on reception of the implicit mode BU already, while the signaling of the delegated prefixes to the MR only occurs when the DHCPv6 PD signaling occurs, so this does work.

> not know either the prefixes assigned to the MR.

This requires switching back and forth between modes.

> is possible, then both approaches would be valid.

Yup.

But the second approach provides no additional feature (I don't consider ending up in explicit mode when the prefix comes from the upstream network a feature by itself) at the cost of additional complexity (switching between two modes.)

So I stand by my conclusion below that implicit mode should be made the default NEMO mode when DHCP prefix delegation is in use:

> >    initiates a DHCPv6 message exchange with a DHCPv6 Rebind message
> >    as described in section 18.1.2 of RFC 3315 and section 12.1 of RFC
> >    3633. In this case, only one BU signaling sequence is required.
> >

[...]

[...]

> >    infrastructure.  If the HA is acting as a DHCPv6 relay agent, the
> >    HA SHOULD add a route to the delegated prefix and advertise that
> >    route after receiving a binding update for the prefix from the RR
> >    [RFC3963].
> >

I believe the HA advertising reachability to the mobile network is covered appropriately in the following two excerpts of RFC 3963 and we do not need to say anything special:

- Section 3:

   When a Correspondent Node sends a data packet to a node in the Mobile
   Network, the packet is routed to the Home Agent that currently has
   the binding for the Mobile Router.  The Mobile Router's network
   prefix would be aggregated at the Home Agent, which would advertise
   the resulting aggregation. Alternatively, the Home Agent may receive
   the data packets destined to the Mobile Network by advertising routes
   to the Mobile Network Prefix.  The actual mechanism by which these
   routes are advertised is outside the scope of this document.

- Section 6.3:

   To receive packets meant for the Mobile Network, the Home Agent
   advertises reachability to the Mobile Network.  If the Home Link is
   configured with an aggregated prefix and the Mobile Network Prefix is
   aggregated under that prefix, then the routing changes related to the
   Mobile Network may be restricted to the Home Link.  If the Home Agent
   is the only default router on the Home Link, routes to the Mobile
   Network Prefix are aggregated naturally under the Home Agent, which
   does not have to do anything special.

What is missing that needs to be specified in the NEMO PD spec?

> >    NEMO explicit mode is recommended to take advantage of the
> >    function already defined for NEMO.
> >
> > implicit mode together with DHCPv6 PD. But besides that, what does
> > "to take advantage of the function already defined for NEMO" means? What

This is the text you suggested in Michaela's review:

        "NEMO explicit mode is recommended to take advantage of
        the function (i.e. the prefixes are included in the BU,
        carried in MNP options) already defined in NEMO for the HA
        to know about the delegated prefixes of the MR."

Hmm... The network delegates a prefix to a MR, then the function is for the MR to tell the prefix back to the network?

That looks more like a NOOP than a function... I also don't know what are the advantages of a NOOP in the context of NEMO...

[...]

> > I also find the statement above on integrity protection being
> > provided by the mobile network infrastructure as vague. What is the mobile
> > network infrastructure? Is it the IPsec Security Associations that
> > are present between the MR and HA.
>

Ok. If so, I believe this should be spelled out, e.g., "[...] which can be provided by the the IPsec security association protecting data packets between the MR and the HA as specified in RFC 4877."

Also, we could recommend here the use of IPsec security associations that protect integrity of DHCPv6 messages exchanged between the MR and the HA, when the data packets are not protected.

That would be useful secure NEMO PD by leveraging onto the keying material that already has to be deployed as part of securing MIPv6 signaling.

> authentication is provided in the MR-HA path (i.e. use of IPsec for
> data plane protection in NEMO) then nothing else is needed. If not,
> then DHCPv6 authentication as described in section "Authentication of DHCP

Since MIPv6 already requires the use of IPsec I do not believe it is practical to recommend the use of an alternative security mechanism for protection of NEMO PD. The section "Authentication of DHCP messages" describes different security mechanisms, one of them being IPsec, the other being a keyed HMAC

I also do not believe we should recommend use of the DHCPv6 security mechanism as it does not come with a standard automated key management and BCP 107 recommends (SHOULD) the use of automated key management.

> > I think we need not to recommend DHCPv6 authentication as a
> > protection mechanism in the context of NEMO. The use of NEMO already requires
> > IPsec Security Associations between the HA and the MR. I see no
> > reason why we should not leverage on these...
>

We should recommend one, that is good for interoperability, and we should recommend one that have the required properties, i.e., not DHCPv6 authentication.

--julien

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 16 Apr 2010 12:31:11 +0200

Hi Julien,

Thanks for your comments. Please see some ones from me below. I'm also
cutting through parts we agree.

[...]
> Configuration options are not a goal per se, and are often detrimental
> to inter-operability and overall system simplicity.

Well, I think an operator may want to have a box running as DHCPv6
server and several MRs, each of them running a DHCPv6 relay instance.
After the discussions we have had, I do realise that this approach is
more complex (it needs some sync between the NEMO and DHCPv6 stack so
the MR knows the MNPs of the MR even before the MR requests them via
DHCPv6, more about this below). If the WG considers that this is a
scenario that does not deserve our attention, I'm fine with only
supporting DHCPv6 server co-located with the HA.

[...]

> A prefix can be allocated to the MR on reception of the implicit mode
> BU already, while the signaling of the delegated prefixes to the MR
> only occurs when the DHCPv6 PD signaling occurs, so this does work.

OK, so you mean that the prefix assignment to MRs is not really done
on-the-fly, but configured before-hand at the DHCPv6 server and HA so
both of them know the prefixes to be allocated to each MR, is that
right? If that is the case, I agree the implicit mode only approach will
work, but I'm not sure if this is a realistic assumption.

> This requires switching back and forth between modes.

Yes, but the main problem I see is the same that I highlighted above,
the HA and DHCPv6 server have to know already the prefixes associated to
the MRs, no real dynamic allocation could be done, unless some protocol
is used between them to sync.

> But the second approach provides no additional feature (I don't
> consider ending up in explicit mode when the prefix comes from the
> upstream network a feature by itself) at the cost of additional
> complexity (switching between two modes.)

I agree here. I'm just pointing out that the implicit mode has also some
issues/implicit assumptions that have to be make clear.

[...]

> I believe the HA advertising reachability to the mobile network is
> covered appropriately in the following two excerpts of RFC 3963 and we
> do not need to say anything special:
> 
> - Section 3:
> 

Well, if the DHCPv6PD server is co-located with the HA, I assume that
this already implies that the DHCPv6PD server is aggregating the
prefixes it delegates (anchor point for them) and therefore the HA is
able to intercept packets addressed to the prefix delegated to the MR.
If a DHCPv6PD relay instance is co-located with the HA, then I assume
that the HA should really ensure that the traffic addressed to the
delegated prefix is forwarded through the HA. Isn't that right?

NEMO B.S. does not go into routes are advertised, but NEMO PD spec may
explain how this should be done depending on whether a DHCPv6 relay or a
server is co-located with the HA.

[...]

> Ok. If so, I believe this should be spelled out, e.g., "[...] which
> can be provided by the the IPsec security association protecting data
> packets between the MR and the HA as specified in RFC 4877."

Agree.

> 
> Also, we could recommend here the use of IPsec security associations
> that protect integrity of DHCPv6 messages exchanged between the MR and
> the HA, when the data packets are not protected.

Agree as recommendation, not enforcement (DHCPv6 authentication can also
be used instead).

> 
> That would be useful secure NEMO PD by leveraging onto the keying
> material that already has to be deployed as part of securing MIPv6
> signaling.
> 
> Since MIPv6 already requires the use of IPsec I do not believe it is
> practical to recommend the use of an alternative security mechanism
> for protection of NEMO PD. The section "Authentication of DHCP
> messages" describes different security mechanisms, one of them being
> IPsec, the other being a keyed HMAC
> 
> I also do not believe we should recommend use of the DHCPv6 security
> mechanism as it does not come with a standard automated key management
> and BCP 107 recommends (SHOULD) the use of automated key management.
> 
> We should recommend one, that is good for interoperability, and we
> should recommend one that have the required properties, i.e., not
> DHCPv6 authentication.

I'm fine with recommending one, but I'd prefer to keep documented both
approaches.

Kind Regards,

Carlos