Subject: Re: [MEXT] WGLC for draft-ietf-mext-nemo-pd-04.txt

From: Jean-Michel Combes <[email-masked]>
Date: Fri, 2 Apr 2010 18:00:36 +0200

Hi,

Here are my comments/questions regarding this draft:

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

<JMC>
s/section 12.1 of RFC 3633/section 11.1 of RFC 3633
<JMC>

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

<JMC>
At first, it is not clear whether the first BU message is a MIPv6 BU
(i.e. R flag set to 0) or a NEMO BU (i.e. R flag set to 1) without MNP
inside it.
Now, as it is said in RFC 3963 that "A Mobile Router MUST implement at
least one mode and MAY implement both.", and OTOH, knowing that a MR
is also a MN, I would recommend to use a MIPv6 BU (i.e. R flag set to
0) for the first BU message.
In case the MR only implements the NEMO Explicit Mode, it sends a new
BU to the HA now carrying the MNP, as it is already said in the
document.
In case the MR only implements the NEMO Implicit Mode, we may assume
that the HA is able to know the MNP allocated to the MR (e.g. DHCP
snooping).
<JMC>

[snip]

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.

<JMC>
IMHO, it would be simplest to reuse or to reference (one part of) the
text in the RFC 3775, section 10.4.4.
<JMC>

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.

<JMC>
Warning: following the Relay-Agent configuration described in 3.3.1,
there is no encapsulation (i.e. DHCPv6 messages between the MR and the
HA are not exchanged through the tunnel) but RH2/HoA_opt are used (cf.
RFC 3775, section 10.4.2 and section 11.3.1).
<JMC>

[snip]

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

[snip]

3.8.  Other DHCPv6 functions
<JMC>
IMHO, the section is out of scope.
<JMC>

[snip]

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

   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.

   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.

<JMC>
Clarification question: Delayed Authentication Protocol requires
pre-shared keys, so from where do they come from?
Comment: Delayed Authentication Protocol uses HMAC-MD5 which is not a
real strong crypto algorithm. Maybe, a warning regarding the weakness
of this algorithm should be added.
<JMC>

   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.  In this scenario, the mobile network
   infrastructure will only protect the DHCPv6 traffic between the RR
   (MR) and the relay agent (HA).  The following text, based on Section
   21.1 of RFC 3315, describes how appropriate security can be provided
   between a DHCPv6 relay agent and server.

      DHCPv6 relay agents and servers MAY use IPsec mechanisms for IPv6
      [RFC4301] to exchange messages securely.  DHCPv6 relay agents and
      servers that support secure relay agent to server or relay agent
      to relay agent communication use IPsec under the following
      conditions:

      Selectors       DHCPv6 relay agents are manually configured with
                      the addresses of the DHCPv6 server to which DHCPv6
                      messages are to be forwarded.  Each DHCPv6 server
                      that will be using IPsec for securing DHCPv6
                      messages must also be configured with a list of
                      the DHCPv6 relay agents to which messages will be
                      returned.  The selectors for the DHCPv6 relay
                      agents and servers will be the pairs of addresses
                      defining DHCPv6 relay agents and servers that
                      exchange DHCP messages on the DHCPv6 UDP ports 546
                      and 547.

      Mode            DHCPv6 relay agents and servers use transport mode
                      and ESP.  The information in DHCPv6 messages is
                      not generally considered confidential, so
                      encryption need not be used (i.e., NULL encryption
                      can be used).

      Key management  If the HA providing the DHCPv6 relay agent
                      function and the DHCPv6 servers are both
                      administered by the same organization, public key
                      schemes are not necessary.  Because the relay
                      agents and servers must be manually configured,
                      manually configured key management may suffice,
                      but does not provide defense against replayed
                      messages.  Accordingly, IKE with preshared secrets
                      SHOULD be supported.

      Security policy DHCPv6 messages between relay agents and servers
                      should only be accepted from DHCPv6 peers as
                      identified in the local configuration.

      Authentication  Shared keys, indexed to the source IP address of
                      the received DHCPv6 message, are adequate in this
                      application.

<JMC>
What is the security when a DHCPv6 Relay-Agent is collocated with the MR?
<JMC>

Hope that helps and thanks in advance for your reply.

Best regards.

JMC.


2010/3/29 marcelo bagnulo braun <[email-masked]>:
> Hi,
>
> This note issues the WGLC for draft-ietf-mext-nemo-pd-04.txt.
>
> Please review and send comments before sunday the 11 of april.
>
> For your convenience, find the draft information attached.
>
> Regards, marcelo
>
> -------- Mensaje original --------
> Asunto:         I-D Action:draft-ietf-mext-nemo-pd-04.txt
> Fecha:  Mon, 8 Mar 2010 14:15:02 -0800 (PST)
> De:     [email-masked]
> Responder a:    [email-masked]
> Para:   [email-masked]
> CC:     [email-masked]
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Mobility EXTensions for IPv6 Working Group
> of the IETF.
>
>
>        Title           : DHCPv6 Prefix Delegation for NEMO
>        Author(s)       : R. Droms, et al.
>        Filename        : draft-ietf-mext-nemo-pd-04.txt
>        Pages           : 17
>        Date            : 2010-03-08
>
> One aspect of network mobility support is the assignment of a prefix
> or prefixes to a Mobile Router (MR) for use on the links in the
> Mobile Network.  DHCPv6 prefix delegation can be used for this
> configuration task.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-04.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
>
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 05 Apr 2010 11:01:17 +0200

Hi Jean-Michel,

Thanks a lot for the comments. Please see some answers/comments inline
below...

> s/section 12.1 of RFC 3633/section 11.1 of RFC 3633

You are right. Fixed, thanks.

> that the HA is able to know the MNP allocated to the MR (e.g. DHCP

This is something I also thought of, but RFC3963 does not allow to
change the registration type dynamically (section 6.2 of RFC3963):

   If the Home Agent has a valid binding cache entry for the Mobile 
Router, and if the Binding Update has the Mobile Router Flag (R) set
   to a value different from that in the existing binding cache entry,
   then the Home Agent MUST reject the Binding Update and send a Binding
   Acknowledgement with status set to 139 (Registration type change
   disallowed).  However, if the Binding Update is a de-registration
   Binding Update, the Home Agent ignores the value of the Mobile Router
   Flag (R).

That's why it seems better to relax RFC 3963 to support changing from
implicit to explicit signalling. 

> text in the RFC 3775, section 10.4.4.

Yes, agree. What about the following text?

   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). The DHCPv6 messages exchanged between the HA and
   the MR MUST use the MR-HA tunnel as described in Section 10.4.4
   of RFC 3775.

> RFC 3775, section 10.4.2 and section 11.3.1).

I don't fully understand your point here. The Relay-Agent configuration
also requires encapsulation between the MR and the HA (unicast DHCPv6PD
over the MR-HA tunnel as depicted in Figure 3), why do you think no
encapsulation is/should be used?

> pre-shared keys, so from where do they come from?

We assume the same security mechanism than in DHCPv6 base specification,
therefore the pre-shared keys (as specified in RFC3315) "are initially
distributed to the client through some out-of-band mechanism". Do you
think the NEMO-PD use case requires to specify this further?

> of this algorithm should be added.

I don't have a strong opinion here. I'd say that this is more related to
DHCPv6 security, rather than to NEMO-PD.

> What is the security when a DHCPv6 Relay-Agent is collocated with the MR?

The same security considerations that when the MR is acting as RR apply
there, i.e. message integrity protection should be provided by the
network infrastructure between the MR and the HA or, in case this is not
provided, the HA and MR should se DHCPv6 authentication as described in
section "Authentication of DHCP messages" of the DHCPv6 specification
[RFC3315].

Thanks again for the comments!

Kind Regards,

Carlos

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 06 Apr 2010 16:21:04 +0200

JMC thanks for the comments that I support mostly.  I also agree and
disagree with some parts of the draft.  Below are comments.

Le 02/04/2010 18:00, Jean-Michel Combes a écrit :
> <JMC> s/section 12.1 of RFC 3633/section 11.1 of RFC 3633 <JMC>
>

I don't see the necessity to modify the NEMO MIP6 extensions for the
sake of combining with DHCP.

> <JMC> At first, it is not clear whether the first BU message is a
> MIPv6 BU (i.e. R flag set to 0) or a NEMO BU (i.e. R flag set to 1)
> without MNP inside it.

Right, it is unclear.

> Now, as it is said in RFC 3963 that "A Mobile Router MUST implement
> at least one mode and MAY implement both.", and OTOH, knowing that a
> MR is also a MN, I would recommend to use a MIPv6 BU (i.e. R flag set
> to 0) for the first BU message.

My preference is to have a complete decouple between the MIP6 protocol
and the DHCPv6 protocol.  This is what happens with most other
protocols: DHCP stays independent and happens first.

I propose this sequence:

1 - DHCP messaging: Solicit, Advertise, Req, Ack and then
2 - MIP messaging: DHAAD, BU/BAck.

> document. In case the MR only implements the NEMO Implicit Mode, we
> may assume that the HA is able to know the MNP allocated to the MR
> (e.g. DHCP snooping).

snooping, hmmm, disgreeing.

>  link) and may be sent between the HA and the MR through the tunnel.

I do not prefer the DHCP packets to happen through a tunnel.

> <JMC> IMHO, it would be simplest to reuse or to reference (one part
> of) the text in the RFC 3775, section 10.4.4. <JMC>
>
> HA.

I agree.

> In this configuration, the relay agent function is co-located in the
> MR with the DHCPv6 client function (see Figure 3.  Rather than using

Parenthesis missing.

Anyways, the co-location of Relay and MR are an option only.  I prefer
to describe the first non-optional features, like letting the Relay be
the Access Router.

> multicast to send DHCPv6 messages through the tunnel to the DHCPv6
> server, the DHCPv6 client in the MR hands any outbound DHCPv6
> <JMC> Warning: following the Relay-Agent configuration described in
> 3.3.1, there is no encapsulation (i.e. DHCPv6 messages between the
> MR and the HA are not exchanged through the tunnel) but RH2/HoA_opt
> are used (cf. RFC 3775, section 10.4.2 and section 11.3.1). <JMC>

I agree.

> unicast DHCPv6 messages to the DHCPv6 server.

"Unicast" but tunnelled, right?

> 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

"the to the" makes it very difficult to parse and understand.  I am not
sure I agree with this even if it were a typo.

> DHCPv6 server: either the DHCPv6 server or a relay agent that will
> forward message to the DHCPv6 server.

A DHCPv6 server wouldn't usually forward a message to another 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.
>
> [snip]
>
>
> 3.8.  Other DHCPv6 functions <JMC> IMHO, the section is out of scope.
> <JMC>
>
> [snip]
>
>
> Mobile Networks.

Rather Moving Networks maybe?

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

WEll... there may be a new risk.  Introduced by the fact that nobody
forces the MR to put in BU the MNP it received with DHCP.  I
think we should write text that stipulates that MR MUST put prefix
obtained with the DHCP in the BU, if at all.

> network infrastructure between the MR and the HA.

YEs, even if DHCP and MIP are each protected the combination is not
necessarily secure.

> <JMC> Clarification question: Delayed Authentication Protocol
> requires pre-shared keys, so from where do they come from? Comment:
> Delayed Authentication Protocol uses HMAC-MD5 which is not a real
> strong crypto algorithm. Maybe, a warning regarding the weakness of
> this algorithm should be added. <JMC>
>
> servers that support secure relay agent to server or relay agent to
> relay agent communication use IPsec under the following conditions:
>
> Selectors       DHCPv6 relay agents are manually configured with the
> addresses of the DHCPv6 server to which DHCPv6 messages are to be
> forwarded.  Each DHCPv6 server that will be using IPsec for securing
> DHCPv6 messages must also be configured with a list of the DHCPv6
> relay agents to which messages will be returned.  The selectors for
> the DHCPv6 relay agents and servers will be the pairs of addresses
> defining DHCPv6 relay agents and servers that exchange DHCP messages
> on the DHCPv6 UDP ports 546 and 547.
>
> and ESP.  The information in DHCPv6 messages is not generally
> considered confidential, so encryption need not be used (i.e., NULL
> encryption can be used).
>
> Key management  If the HA providing the DHCPv6 relay agent function
> and the DHCPv6 servers are both administered by the same
> organization, public key schemes are not necessary.  Because the
> relay agents and servers must be manually configured, manually
> configured key management may suffice, but does not provide defense
> against replayed messages.  Accordingly, IKE with preshared secrets
> SHOULD be supported.
>
> should only be accepted from DHCPv6 peers as identified in the local
> configuration.
>
> Authentication  Shared keys, indexed to the source IP address of the
> received DHCPv6 message, are adequate in this application.
>
> <JMC> What is the security when a DHCPv6 Relay-Agent is collocated
> with the MR? <JMC>

Good question.

Alex

> 2010/3/29 marcelo bagnulo braun<[email-masked]>:
>> Hi,
>>
>> -------- Mensaje original -------- Asunto:         I-D
>> Action:draft-ietf-mext-nemo-pd-04.txt Fecha:  Mon, 8 Mar 2010
>> 14:15:02 -0800 (PST) De:     [email-masked] Responder a:
>> [email-masked] Para:   [email-masked] CC:
>> [email-masked]
>>
>>
>>
>>  directories. This draft is a work item of the Mobility EXTensions
>>  for IPv6 Working Group of the IETF.
>>
>>
>> Title           : DHCPv6 Prefix Delegation for NEMO Author(s) : R.
>>  Droms, et al. Filename        : draft-ietf-mext-nemo-pd-04.txt
>> Pages           : 17 Date : 2010-03-08
>>
>> One aspect of network mobility support is the assignment of a
>> prefix or prefixes to a Mobile Router (MR) for use on the links in
>> the Mobile Network.  DHCPv6 prefix delegation can be used for this
>> configuration task.
>>
>> _______________________________________________ MEXT mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/mext
>>
>>
> _______________________________________________ MEXT mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mext
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 07 Apr 2010 13:57:56 +0200

[re-sending after 24h wait and no reception]

Right, it is unclear.

I propose this sequence:

I agree.

Parenthesis missing.

I agree.

Good question.

Alex

---

From: Jean-Michel Combes <[email-masked]>
Date: Thu, 8 Apr 2010 16:27:20 +0200

Hi Carlos,

[snip]

> implicit to explicit signalling.

<JMC>
OK, I see.
So, the draft should clearly mention that it will update RFC 3963.
<JMC>

>   the MR MUST use the MR-HA tunnel as described in Section 10.4.4

<JMC>
Fine for me.
<JMC>

> encapsulation is/should be used?

<JMC>
Because:
- from the HA to the MR, the RH2 MUST be used (cf. 10.4.2 in RFC 3775)
- from the MR to the HA (in case the MR is a DHCP-Relay, and so
messages are unicasted - cf. 3.3.2 in the draft), the HoA Option MUST
be used (cf. 11.3.1, RO case, in RFC 3775)

So, if you want to tunnel all DHCPv6 messages (use the IP-in-IP tunnel
and not the RH2/HoA_opt), you should clearly mention this modifies the
MIPv6 specification.
<JMC>

[snip]

> think the NEMO-PD use case requires to specify this further?

<JMC>
Maybe, to add what you said in your reply (i.e. "We assume the same
security mechanism than in DHCPv6 base specification, therefore the
pre-shared keys (as specified in RFC3315) are initially distributed to
the client through some out-of-band mechanism") is enough (but
important to recall, IMHO).
<JMC>

> DHCPv6 security, rather than to NEMO-PD.

<JMC>
AFAIK, I am not aware there is a work regarding this point in the dhc
wg ... don't hesitate to correct me :)
So, IMHO, a warning should be useful.
<JMC>

> section "Authentication of DHCP messages" of the DHCPv6 specification

<JMC>
So, clarification text regarding this case is needed because I was
ready to bet that IPsec would be used :)
<JMC>

Best regards.

JMC.

---

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

Hi Jean-Michel,

Some comments below.

> So, the draft should clearly mention that it will update RFC 3963.

OK, I'll modify it so it is clearly mentioned. Note that there are other
comments about this way of operation, so it might be that a result of
the ongoing discussion, we change this part of the draft and then your
comment might not apply.

> >   the MR MUST use the MR-HA tunnel as described in Section 10.4.4

OK. Some other people commented also about this section. I'll send a
separate e-mail about this.

> and not the RH2/HoA_opt), you should clearly mention this modifies the

As commented before, I'll send a separate e-mail for this issue.

> important to recall, IMHO).

Here I'd prefer not to add text about security issues that are already
cover by other specs and that are not directly related/caused by the use
of DHCPv6PD for NEMO. We already point to the section "Authentication of
DHCP messages" of RFC 3315, so this should be enough, IMHO.

> So, IMHO, a warning should be useful.

As before, I'm not sure we need to deal with pure DHCPv6 security issues
in this draft, since the weaknesses that you point out are not caused by
NEMO-PD.

> ready to bet that IPsec would be used :)

We have some other comments about the security section. Once most of the
rest are closed, I'll revise this to check whether it still applies or
not and how.

Thanks!

---

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

Hi Alex,

> disagree with some parts of the draft.  Below are comments.

Thanks for your comments. Please see some comments inline below.

> sake of combining with DHCP.

Well, the draft proposes one way of doing it. Sure there might be
others, but the proposed update to RFC 3963 is IMHO minor and allows for
a simple protocol for NEMO-PD with DHCPv6. Do you see a major issue with
the proposed change?

> > MIPv6 BU (i.e. R flag set to 0) or a NEMO BU (i.e. R flag set to 1)

As I mentioned im my reply to JMC, changing the registration mode (R
flag) is not allowed by RFC 3963.

> 2 - MIP messaging: DHAAD, BU/BAck.

In your proposal, how would you propose to perform the DHCP signalling
if not benefiting from the MIP mechanisms (i.e. tunneling). Current
approach in the draft basically follow your sequence, but requires a
first registration (with no prefix) just to allow the MR use communicate
with the HA in order to exchange the DHCPv6PD signaling.

> I do not prefer the DHCP packets to happen through a tunnel.

Well, unicasting DHCP signaling between MR and DR is another approach
that could also be followed, but that one would need additional
considerations to be taken into account (i.e. security ones). I have not
personally thought how the solution would look like in that case. Do you
think current solution has unsolved issues that a non-tunnel (i.e.
unicast-based) DHCPv6PD solution would avoid/solve?

> > MR with the DHCPv6 client function (see Figure 3.  Rather than using

Thanks, Michaela also pointed this out and it's now fixed.

> to describe the first non-optional features, like letting the Relay be

The AR? that would require (if I'm not wrong) interactions between the
visited and the home network, that would probably make the solution more
complex.

> > are used (cf. RFC 3775, section 10.4.2 and section 11.3.1). <JMC>

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

> "Unicast" but tunnelled, right?

Yes. I think this make security easier.

> sure I agree with this even if it were a typo.

Typo fixed, thanks.

> A DHCPv6 server wouldn't usually forward a message to another DHCPv6 server.

Yes, but that was not the intention of what was written. I've added a
comma now, so it reads: "For the purposes of NEMO, the relay agent
assumes that the HA for the MR hosts the next hop in the path to the
DHCPv6 server: either the DHCPv6 server, or a relay agent that will
forward message to the DHCPv6 server."

Better now?

> Rather Moving Networks maybe?

Yep or NEMO. I actually prefer NEMO because is the acronym for Mobile
Networks (if I recall it correctly, it comes from "NEtwork that MOves"),
but it's better than "Mobile Network" because sometimes it leads to
confusion with telephone celular networks.

> obtained with the DHCP in the BU, if at all.

Agree some text about that should be added to the draft. I'll try to
come up with something for -05.

> YEs, even if DHCP and MIP are each protected the combination is not

I agree that the statement "if A is secure, and B is secure, the
combination of A and B is secure" is not true for all the cases.
However, I do thing that with the current approach for NEMO-PD the
combination is secure (this still needs to address your comment about
ensuring that the prefix obtained via DHCPv6PD is the one included in
the NEMO BU).

Thanks!

Carlos

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Apr 2010 17:29:41 +0200

Le 11/04/2010 19:24, Carlos Jesús Bernardos Cano a écrit :
>> JMC thanks for the comments that I support mostly.  I also agree
>> and disagree with some parts of the draft.  Below are comments.
>
>>> whenever it establishes an MR-HA tunnel to its HA.  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.
>>>
>>> <JMC>  s/section 12.1 of RFC 3633/section 11.1 of RFC 3633<JMC>
>>>
>>> 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 don't see the necessity to modify the NEMO MIP6 extensions for
>> the sake of combining with DHCP.
>
> others, but the proposed update to RFC 3963 is IMHO minor

Minor?  The implementation does not seem minor.  I am not sure an
implementation of NEMOv6 MR could change dynamically between explicit
and implicit modes.

> and allows for a simple protocol for NEMO-PD with DHCPv6. Do you see
>  a major issue with the proposed change?

YEs - implementation: how do you propose to make the NEMOv6 MR
dynamically switch between explicit and implicit mode?

Do you want to modify the DHCP implementation to tell the NEMOv6 MR
implementaiton when to change modes?

I propose to keep them (the two implementations: DHCP and NEMO)
separated no interaction between the two.

>>> <JMC>  At first, it is not clear whether the first BU message is
>>>  a MIPv6 BU (i.e. R flag set to 0) or a NEMO BU (i.e. R flag set
>>>  to 1) without MNP inside it.
>>
>> Right, it is unclear.
>

Right.  The bit 'R' should be set if this is a Mobile Router.  If it's
not a Mobile Router then reset it.  Don't mix the two.

My opinion is, of course, IMHO.

>>> Now, as it is said in RFC 3963 that "A Mobile Router MUST
>>> implement at least one mode and MAY implement both.", and OTOH,
>>> knowing that a MR is also a MN, I would recommend to use a MIPv6
>>>  BU (i.e. R flag set to 0) for the first BU message.
>>
>> My preference is to have a complete decouple between the MIP6
>> protocol and the DHCPv6 protocol.  This is what happens with most
>> other protocols: DHCP stays independent and happens first.
>>
>> I propose this sequence:
>>
>> 1 - DHCP messaging: Solicit, Advertise, Req, Ack and then 2 - MIP
>> messaging: DHAAD, BU/BAck.
>>
>
> In your proposal, how would you propose to perform the DHCP
> signalling if not benefiting from the MIP mechanisms (i.e.
> tunneling).

Start DHCP prefix delegation on the MR, without tunnel.  Once the prefix
is obtained only _then_  launch the BU.

> Current approach in the draft basically follow your sequence, but
> requires a first registration (with no prefix) just to allow the MR
> use communicate with the HA in order to exchange the DHCPv6PD
> signaling.

One could exchange the DHCPv6PD w/o having the the IP tunnel set up.

>>> In case the MR only implements the NEMO Explicit Mode, it sends a
>>> new BU to the HA now carrying the MNP, as it is already said in
>>> the document. In case the MR only implements the NEMO Implicit
>>> Mode, we may assume that the HA is able to know the MNP allocated
>>> to the MR (e.g. DHCP snooping).
>>
>>> 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.
>>
> Well, unicasting DHCP signaling between MR and DR is another
> approach that could also be followed, but that one would need
> additional considerations to be taken into account (i.e. security
> ones).

I think it is very secure already.  It is more secure than teaching the
MR to some time act as a MH (Mobile Host).

With your method, the MR does not use DHCP security at all.  I.e. it
could use MIP security to protect DHCP messages and fool the HA about
the prefix it is sending in the BU (different than the prefix it
obtained with DHCP).

> I have not personally thought how the solution would look like in
> that case. Do you think current solution has unsolved issues that a
> non-tunnel (i.e. unicast-based) DHCPv6PD solution would avoid/solve?

YEs  - security.  Current (draft's) solution has security weaknesses: it
uses DHCP without the native DHCP security.  The risk is that MR can
fool the HA about the prefix it puts in its BU (different than the
prefix  it obtains from DHCP).

>>> SHOULD use multicast DHCPv6 messages as described in RFC 3315
>>> over that tunnel.
>>>
>>> <JMC>  IMHO, it would be simplest to reuse or to reference (one
>>> part of) the text in the RFC 3775, section 10.4.4.<JMC>
>>>
>>> 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.
>>
>> I agree.
>>
>>> In this configuration, the relay agent function is co-located in
>>>  the MR with the DHCPv6 client function (see Figure 3.  Rather
>>> than using
>>
>> Parenthesis missing.
>
>> Anyways, the co-location of Relay and MR are an option only.  I
>> prefer to describe the first non-optional features, like letting
>> the Relay be the Access Router.
>
> The AR? that would require (if I'm not wrong) interactions between
> the visited and the home network, that would probably make the
> solution more complex.

Well - why?  Typical interactions between the AR (a Relay) and the home
network is pure unicast - suffices it to have the right filters open in
the firewall.

Of course the visited domain has to open DHCPv6 filters to let DHCPv6PD
through, but so it has to do with MIPv6 - must open firewall for MIPv6
to pass through.

>>> 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.
>>>
>>> <JMC>  Warning: following the Relay-Agent configuration described
>>> in 3.3.1, there is no encapsulation (i.e. DHCPv6 messages between
>>> the MR and the HA are not exchanged through the tunnel) but
>>> RH2/HoA_opt are used (cf. RFC 3775, section 10.4.2 and section
>>> 11.3.1).<JMC>
>>
>> I agree.
>

I don't think so - you try to use MIPv6 security applied on DHCPv6.  I
propose to use DHCPv6 native security on DHCP and MIP security on MIP.

>>> 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
>>
>> "the to the" makes it very difficult to parse and understand.  I am
>> not sure I agree with this even if it were a typo.
>
> Typo fixed, thanks.
>
>>
>>> DHCPv6 server: either the DHCPv6 server or a relay agent that
>>> will forward message to the DHCPv6 server.
>>
> Yes, but that was not the intention of what was written. I've added
> a comma now, so it reads: "For the purposes of NEMO, the relay agent
>  assumes that the HA for the MR hosts the next hop in the path to
> the DHCPv6 server: either the DHCPv6 server, or a relay agent that
> will forward message to the DHCPv6 server."
>
> Better now?

That is a way of doing it (use DHCP through tunnel) - I think it has
security issues, and implementations issues..  I prefer DHCP not through
tunnel.

>>> configure the DHCPv6 relay agent to forward DHCPv6 messages to
>>> the HA.
>>>
>>> [snip]
>>>
>>>
>>> 3.8.  Other DHCPv6 functions<JMC>  IMHO, the section is out of
>>> scope. <JMC>
>>>
>>> [snip]
>>>
>>>
>>> This document describes the use of DHCPv6 for prefix delegation
>>> in Mobile Networks.
>>
> Yep or NEMO. I actually prefer NEMO because is the acronym for
> Mobile Networks (if I recall it correctly, it comes from "NEtwork
> that MOves"), but it's better than "Mobile Network" because sometimes
> it leads to confusion with telephone celular networks.

Ok me too.

>>> section of the DHCPv6 base specification [RFC3315] and the
>>> "Security Considerations" of the DHCPv6 Prefix Delegation
>>> specification [RFC3633].
>>
>> WEll... there may be a new risk.  Introduced by the fact that
>> nobody forces the MR to put in BU the MNP it received with DHCP. I

WEll yes, and adding up text about this could lead to a preferred
solution where DHCP doesn't run through the MIP tunnel, instead uses its
own security.

>>> message integrity protection, which can be provided by the
>>> mobile network infrastructure between the MR and the HA.
>>
>> YEs, even if DHCP and MIP are each protected the combination is
>> not necessarily secure.
>
> combination is secure (this still needs to address your comment
> about ensuring that the prefix obtained via DHCPv6PD is the one
> included in the NEMO BU).

Well, not sure.

The MIP keys are proper to MIP configuration.  The DHCP traffic between
HA and the DHCP server will go unprotected.

Also, nothing in the spec prevents the MR to put in a BU a prefix which
was not allocated to it by HA.  It can't whatever text we write.

I think we would better rely on each protocol's security and acknowledge
the few weaknesses left, rather than pretending MIP security could cover
everything just because it's a secure tunnel.

Alex

>
> Thanks!
>
> Carlos
>
>>
>>> 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.
>>>
>>> requires pre-shared keys, so from where do they come from?
>>> Comment: Delayed Authentication Protocol uses HMAC-MD5 which is
>>> not a real strong crypto algorithm. Maybe, a warning regarding
>>> the weakness of this algorithm should be added.<JMC>
>>>
>>> physical node, the HA will act as a DHCPv6 relay agent between
>>> the MR and the DHCPv6 server.  In this scenario, the mobile
>>> network infrastructure will only protect the DHCPv6 traffic
>>> between the RR (MR) and the relay agent (HA).  The following
>>> text, based on Section 21.1 of RFC 3315, describes how
>>> appropriate security can be provided between a DHCPv6 relay agent
>>> and server.
>>>
>>> DHCPv6 relay agents and servers MAY use IPsec mechanisms for
>>> IPv6 [RFC4301] to exchange messages securely.  DHCPv6 relay
>>> agents and servers that support secure relay agent to server or
>>> relay agent to relay agent communication use IPsec under the
>>> following conditions:
>>>
>>>  the addresses of the DHCPv6 server to which DHCPv6 messages are
>>>  to be forwarded.  Each DHCPv6 server that will be using IPsec
>>> for securing DHCPv6 messages must also be configured with a list
>>> of the DHCPv6 relay agents to which messages will be returned.
>>> The selectors for the DHCPv6 relay agents and servers will be the
>>> pairs of addresses defining DHCPv6 relay agents and servers that
>>> exchange DHCP messages on the DHCPv6 UDP ports 546 and 547.
>>>
>>> Mode            DHCPv6 relay agents and servers use transport
>>> mode and ESP.  The information in DHCPv6 messages is not
>>> generally considered confidential, so encryption need not be used
>>> (i.e., NULL encryption can be used).
>>>
>>> function and the DHCPv6 servers are both administered by the
>>> same organization, public key schemes are not necessary.  Because
>>> the relay agents and servers must be manually configured,
>>> manually configured key management may suffice, but does not
>>> provide defense against replayed messages.  Accordingly, IKE with
>>>  preshared secrets SHOULD be supported.
>>>
>>> should only be accepted from DHCPv6 peers as identified in the
>>> local configuration.
>>>
>>>  the received DHCPv6 message, are adequate in this application.
>>>
>>> <JMC>  What is the security when a DHCPv6 Relay-Agent is
>>> collocated with the MR?<JMC>
>>
>> Good question.
>>
>> Alex
>>
>>>
>>>
>>>> 14:15:02 -0800 (PST) De:     [email-masked] Responder
>>>> a: [email-masked] Para: [email-masked] CC:
>>>> [email-masked]
>>>>
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line
>>>> Internet-Drafts directories. This draft is a work item of the
>>>> Mobility EXTensions for IPv6 Working Group of the IETF.
>>>>
>>>>
>>>> Title           : DHCPv6 Prefix Delegation for NEMO Author(s) :
>>>> R. Droms, et al. Filename        :
>>>> draft-ietf-mext-nemo-pd-04.txt Pages           : 17 Date :
>>>> 2010-03-08
>>>>
>>>> prefix or prefixes to a Mobile Router (MR) for use on the links
>>>> in the Mobile Network.  DHCPv6 prefix delegation can be used
>>>> for this configuration task.
>>>>
Internet-Drafts are also available by anonymous FTP at:
>>>> Below is the data which will enable a MIME compliant mail
>>>> reader implementation to automatically retrieve the ASCII
>>>> version of the Internet-Draft.
>>>>
>>>>
>>>>
>>>> _______________________________________________ MEXT mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/mext
>>>>
>>>>
>>> _______________________________________________ MEXT mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/mext
>>>
>>
>>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 13 Apr 2010 19:44:58 +0200

Hi Alex,

Thanks for the reply, comments to some (not all yet) of your comments
below.

> implementation of NEMOv6 MR could change dynamically between explicit

Well, I don't think this change is big (from my experience implementing
NEMO, which is somehow limited). Anyway, there is a more important issue
with the implicit-explicit mode and NEMO-PD which I brought in my reply
to Julien's comments. Lets wait until this is clear and we revisit this
(if still applies).

> is obtained only _then_  launch the BU.

I'm not 100% sure, but I think directly sending unicast requests to a
DHCPv6 server from a global IPv6 address is not always supported. That
does not mean we could require the server to implement the required
functionality when used for NEMO-PD...

> the prefix it is sending in the BU (different than the prefix it

In any case, RFC 3963 requires this to be checked:

   "The Home Agent SHOULD be able to prevent a Mobile Router from
   claiming Mobile Network Prefixes belonging to another Mobile Router.
   The Home Agent can prevent such attacks if it maintains a Prefix
   Table and verifies the prefix information provided by the Mobile
   Router against Prefix Table entries.  The Prefix Table SHOULD be used
   by the Home Agent when it processes a Binding Update in explicit
   mode.  It is not required when a dynamic routing protocol is run
   between the Mobile Router and the Home Agent."

Therefore, no matter how the prefix is obtained, the HA needs to check
what the MR includes in the BU (if explicit mode).

Security in the context of the NEMO-PD draft so far was focused on the
integrity of the DHCP messages. For that, either DHCP security can be
used or IPsec in the MR-HA tunnel that is used to forward the DHCP
signalling.

> uses DHCP without the native DHCP security.  The risk is that MR can

Not really, DHCP security is not excluded. It is only mentioned that if
DHCP authentication cannot be used, the IPsec tunnel of NEMO can provide
the required protection (in this case data packets -- or at least DHCP
ones -- should be also encrypted, this is not the MIPv6 default).

> network is pure unicast - suffices it to have the right filters open in

But the AR should be configured to talk to the DHCP server on the home
network of the NEMO. This requires (manual) configuration, security,
etc.

> HA and the DHCP server will go unprotected.

Sure, in this case we assume that data traffic (or at least DHCP
signalling) would be also protected. We just mention that this could be
an alternative way of doing this.

> was not allocated to it by HA.  It can't whatever text we write.

RFC 3963 requires anyway this to be checked. What we can comment on is
how the DHCPv6 server and the HA can interface to share the same view on
what prefixes are delegated to what MRs.

Kind Regards,

Carlos

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Apr 2010 23:57:56 +0200

Le 13/04/2010 19:44, Carlos Jesús Bernardos Cano a écrit :
[...]
>> Start DHCP prefix delegation on the MR, without tunnel.  Once the
>> prefix is obtained only _then_  launch the BU.
>
> DHCPv6 server from a global IPv6 address is not always supported.

I think DHCP could support this config:

MR---AR----Internet---DHCPServer

[...]
>> With your method, the MR does not use DHCP security at all.  I.e.
>> it could use MIP security to protect DHCP messages and fool the HA
>> about the prefix it is sending in the BU (different than the prefix
>> it obtained with DHCP).
>
> Router against Prefix Table entries.

Yes, that is right.  However, the HA has no way to know which prefix was
assigned to the MR by the DHCPServer.  With your method (DHCP through
tunnel) the DHCP messages are invisible to the HA - protected by DHCP's
IPsec.  Your method (sorry, Authors' and yours method) means that the HA 
learns the prefix _only_ when MR tells it to it with an explicit BU - 
too late for HA to check the Prefix Table and ensure security.

Or - for that check in the Prefix Table to work and ensure security the
HA must know the prefix prior to MR sending it a BU.  This can happen
with some mechanism between HA and DHCPServer.

> The Prefix Table SHOULD be used by the Home Agent when it processes a
> Binding Update in explicit mode.  It is not required when a dynamic
> routing protocol is run between the Mobile Router and the Home
> Agent."
>
> Therefore, no matter how the prefix is obtained, the HA needs to
> check what the MR includes in the BU (if explicit mode).

YEs - but check against what?

> Security in the context of the NEMO-PD draft so far was focused on
> the integrity of the DHCP messages. For that, either DHCP security
> can be used or IPsec in the MR-HA tunnel that is used to forward the
> DHCP signalling.
>
>>
>>> that case. Do you think current solution has unsolved issues that
>>> a non-tunnel (i.e. unicast-based) DHCPv6PD solution would
>>> avoid/solve?
>>
>> YEs  - security.  Current (draft's) solution has security
>> weaknesses: it uses DHCP without the native DHCP security.  The
>> risk is that MR can
>
> Not really, DHCP security is not excluded. It is only mentioned that
> if DHCP authentication cannot be used, the IPsec tunnel of NEMO can
> provide the required protection (in this case data packets -- or at
> least DHCP ones -- should be also encrypted, this is not the MIPv6
> default).
>
>>>>> <JMC>   IMHO, it would be simplest to reuse or to reference
>>>>> (one part of) the text in the RFC 3775, section 10.4.4.<JMC>
>>>>>
>>>>> alternative to multicast DHCPv6 messages over the tunnel
>>>>> between the MR and the HA.
>>>>
>>>> I agree.
>>>>
>>>>> In this configuration, the relay agent function is
>>>>> co-located in the MR with the DHCPv6 client function (see
>>>>> Figure 3. Rather than using
>>>>
>>>> Parenthesis missing.
>>>
>>>>  prefer to describe the first non-optional features, like
>>>> letting the Relay be the Access Router.
>>>
>>> The AR? that would require (if I'm not wrong) interactions
>>> between the visited and the home network, that would probably
>>> make the solution more complex.
>>
>> Well - why?  Typical interactions between the AR (a Relay) and the
>> home network is pure unicast - suffices it to have the right
>> filters open in the firewall.
>
> But the AR should be configured to talk to the DHCP server on the
> home network of the NEMO. This requires (manual) configuration,
> security, etc.

That is right.  For this not-through-tunnel DHCP to work the AR Relays
should be configured to talk to the HA.  We could leave that to some
other protocols.

 From MR's perspective just discover the local DHCP Server and ask for a
prefix.  Maybe request it to be _the_ home prefix, or request a prefix
valid in the visited domain.  And let the protocol between AR and the
DHCP Servers be something else.

Maybe the MR wants to use a prefix valid in the visited domain, in order
to avoid encapsulation and triangular routing.  This is a valid scenario
because the only reason to ask for the _home_ prefix is when MR boots
up, i.e. it does not yet have a prefix so no ongoing sessions which need
to be maintained running, which are the only reason to talk to the home
network.

I.e. use DHCP Prefix Delegation to obtain a prefix whatever that is
(home or other) and then send BUs to the domain which assigned that prefix.

In all cases there is a strong need for a Mobile Router to obtain a
prefix prior to doing any MIP signalling - if only to allow for LFNs to
talk to each other.  E.g. I don't want the LFNs in a ship to be unable
to communicate between them simply because the MIP steps failed or HA
unavailable.  Putting MIP before DHCP risks this to happen, because if
MIP tunnel setup unsuccessful then MR can't do DHCP and thus doesn't
have a MNP so the LFNs don't have addresses (other than link-local of
course, but on a ship there would be several links).

(I will check your exchange with Julien too).

Alex

>> Of course the visited domain has to open DHCPv6 filters to let
>> DHCPv6PD through, but so it has to do with MIPv6 - must open
>> firewall for MIPv6 to pass through.
>>
>>>>> 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.
>>>>>
>>>>> <JMC>   Warning: following the Relay-Agent configuration
>>>>> described in 3.3.1, there is no encapsulation (i.e. DHCPv6
>>>>> messages between the MR and the HA are not exchanged through
>>>>> the tunnel) but RH2/HoA_opt are used (cf. RFC 3775, section
>>>>> 10.4.2 and section 11.3.1).<JMC>
>>>>
>>>> I agree.
>>>
>>>>> The use of the relay agent function in the MR allows the MR
>>>>> to unicast DHCPv6 messages to the DHCPv6 server.
>>>>
>> I don't think so - you try to use MIPv6 security applied on
>> DHCPv6. I propose to use DHCPv6 native security on DHCP and MIP
>> security on MIP.
>>
>>>>> relay agent assumes that the HA for the MR hosts the next hop
>>>>> in the path the to the
>>>>
>>>> "the to the" makes it very difficult to parse and understand. I
>>>> am not sure I agree with this even if it were a typo.
>>>
>>> Typo fixed, thanks.
>>>
>>>>
>>> Yes, but that was not the intention of what was written. I've
>>> added a comma now, so it reads: "For the purposes of NEMO, the
>>> the path to the DHCPv6 server: either the DHCPv6 server, or a
>>> relay agent that will forward message to the DHCPv6 server."
>>>
>>> Better now?
>>
>> That is a way of doing it (use DHCP through tunnel) - I think it
>> has security issues, and implementations issues..  I prefer DHCP
>> not through tunnel.
>>
>>>>> 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.
>>>>>
>>>>> [snip]
>>>>>
>>>>>
>>>>> 3.8.  Other DHCPv6 functions<JMC>   IMHO, the section is out
>>>>> of scope.<JMC>
>>>>>
>>>>> [snip]
>>>>>
>>>>>
>>>>> This document describes the use of DHCPv6 for prefix
>>>>> delegation in Mobile Networks.
>>>>
>>> that MOves"), but it's better than "Mobile Network" because
>>> sometimes it leads to confusion with telephone celular networks.
>>
>> Ok me too.
>>
>>>>> 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].
>>>>
>>>> nobody forces the MR to put in BU the MNP it received with
>>>> DHCP. I think we should write text that stipulates that MR
>>>> MUST put prefix obtained with the DHCP in the BU, if at all.
>>>
>>> Agree some text about that should be added to the draft. I'll
>>> try to come up with something for -05.
>>
>> solution where DHCP doesn't run through the MIP tunnel, instead
>> uses its own security.
>>
>>>>> 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.
>>>>
>>>  However, I do thing that with the current approach for NEMO-PD
>>> the combination is secure (this still needs to address your
>>> comment about ensuring that the prefix obtained via DHCPv6PD is
>>> the one included in the NEMO BU).
>>
>> Well, not sure.
>>
>> The MIP keys are proper to MIP configuration.  The DHCP traffic
>> between HA and the DHCP server will go unprotected.
>
> signalling) would be also protected. We just mention that this could
> be an alternative way of doing this.
>
>>
>> Also, nothing in the spec prevents the MR to put in a BU a prefix
>> which was not allocated to it by HA.  It can't whatever text we
>> write.
>
> RFC 3963 requires anyway this to be checked. What we can comment on
> is how the DHCPv6 server and the HA can interface to share the same
> view on what prefixes are delegated to what MRs.
>
> Kind Regards,
>
> Carlos
>
>>
>> I think we would better rely on each protocol's security and
>> acknowledge the few weaknesses left, rather than pretending MIP
>> security could cover everything just because it's a secure tunnel.
>>
>> Alex
>>
>>>
>>> Thanks!
>>>
>>> Carlos
>>>
>>>>
>>>>> 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.
>>>>>
>>>>> <JMC>   Clarification question: Delayed Authentication
>>>>> Protocol requires pre-shared keys, so from where do they
>>>>> come from? Comment: Delayed Authentication Protocol uses
>>>>> HMAC-MD5 which is not a real strong crypto algorithm. Maybe,
>>>>> a warning regarding the weakness of this algorithm should be
>>>>>  added.<JMC>
>>>>>
>>>>> 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.  In this scenario, the
>>>>> mobile network infrastructure will only protect the DHCPv6
>>>>> traffic between the RR (MR) and the relay agent (HA).  The
>>>>> following text, based on Section 21.1 of RFC 3315, describes
>>>>> how appropriate security can be provided between a DHCPv6
>>>>> relay agent and server.
>>>>>
>>>>>  agents and servers that support secure relay agent to
>>>>> server or relay agent to relay agent communication use IPsec
>>>>> under the following conditions:
>>>>>
>>>>> Selectors       DHCPv6 relay agents are manually configured
>>>>> with the addresses of the DHCPv6 server to which DHCPv6
>>>>> messages are to be forwarded.  Each DHCPv6 server that will
>>>>> be using IPsec for securing DHCPv6 messages must also be
>>>>> configured with a list of the DHCPv6 relay agents to which
>>>>> messages will be returned. The selectors for the DHCPv6
>>>>> relay agents and servers will be the pairs of addresses
>>>>> defining DHCPv6 relay agents and servers that exchange DHCP
>>>>> messages on the DHCPv6 UDP ports 546 and 547.
>>>>>
>>>>> generally considered confidential, so encryption need not be
>>>>> used (i.e., NULL encryption can be used).
>>>>>
>>>>>  same organization, public key schemes are not necessary.
>>>>> Because the relay agents and servers must be manually
>>>>> configured, manually configured key management may suffice,
>>>>> but does not provide defense against replayed messages.
>>>>> Accordingly, IKE with preshared secrets SHOULD be supported.
>>>>>
>>>>> Security policy DHCPv6 messages between relay agents and
>>>>> servers should only be accepted from DHCPv6 peers as
>>>>> Authentication  Shared keys, indexed to the source IP
>>>>> address of the received DHCPv6 message, are adequate in this
>>>>>  application.
>>>>>
>>>>>> Action:draft-ietf-mext-nemo-pd-04.txt Fecha:  Mon, 8 Mar
>>>>>> 2010 14:15:02 -0800 (PST) De:     [email-masked]
>>>>>> Responder a: [email-masked] Para:
>>>>>> [email-masked] CC: [email-masked]
>>>>>>
>>>>>>
>>>>>>
>>>>>> Internet-Drafts directories. This draft is a work item of
>>>>>> the Mobility EXTensions for IPv6 Working Group of the
>>>>>> IETF.
>>>>>>
>>>>>>
>>>>>> Author(s) : R. Droms, et al. Filename        :
>>>>>> One aspect of network mobility support is the assignment
>>>>>> of a prefix or prefixes to a Mobile Router (MR) for use on
>>>>>> the links in the Mobile Network.  DHCPv6 prefix delegation
>>>>>> can be used for this configuration task.
>>>>>>
Internet-Drafts are also available by anonymous FTP at:
>>>>>> _______________________________________________ MEXT
>>>>>> mailing list [email-masked]
>>>>>  list [email-masked]

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 13 Apr 2010 16:33:47 -0700

Hi 

The deadline was passed, but I just reviewed it and have some comments :-<

1. RFC3963 mode switch issue is resolved, though the first BU format is not clear (JM already commented).
2. Renewing/Rebinding processes are missed from the spec. There are several scenarios we have to consider, MR rebooting (reboot may cause HA change), MNP expiration, etc.
3. How can HA verify the address ownership (delegation status) when DR is not located at the HA.  The draft introduces "DHCP Relay Agent Assignment Notification Option", but HA must know which prefix is delegated to which mobile router all the time (probably record such information in the prefix table). Otherwise, HA must believe the MNP sent by BU without any verification. 
4. Packet format including IPv6 headers of DHCP messages (any one of them) might be helpful.

thanks,
ryuji

On 2010/03/29, at 1:06, marcelo bagnulo braun wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF.
> 
> 
> <draft-ietf-mext-nemo-pd-04.txt><Parte del mensaje adjunto.txt>_______________________________________________
> MEXT mailing list
> [email-masked]