Subject: [Mip6] General comments/questions on MIPv6 bootstrapping

From: "COMBES Jean-Michel RD-MAPS-ISS" <[email-masked]>
Date: Mon, 24 Oct 2005 19:41:23 +0200

Hi again,

I was waiting for the proposal for the integrated scenario before to do
this email.

I have 2 main comments/questions.

The first one is regarding the fact that we have two (very) different
mechanisms for only one functionality (on one side DNS+IKEv2, on the
other side PANA+AAA+DCHP). So, personally, I am a little afraid how all
this will be managed in the user's terminal and in the MSP's network.
E.g., what will be the trigger in the terminal to know which is the
bootstrapping mechanism the terminal has to use?

My second comment is regarding the interoperability with NEMO. I believe
that if MIPv6 is deployed soon, NEMO will be deployed at the same time
because the protocol is as mature as MIPv6. So I would like to know if
the bootstrapping mechanisms working for MIPv6, will work with NEMO too.
I would like to avoid to add new mechanisms again and so increase the
complexity in a deployement architecture.

Thanks.

Best regards.

JMC.

France Telecom - R&D Division - MAPS/NSS   
Jean-Michel COMBES, Internet/Intranet Security
E-Mail: [email-masked]
Phone: +33 (0)1 45 29 45 94
Fax: +33 (0)1 45 29 65 19
Mobile: +33 (0)6 07 29 30 16 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Oct 2005 13:32:10 -0700

COMBES Jean-Michel RD-MAPS-ISS wrote:
> other side PANA+AAA+DCHP). 

there are 4 mains problems in MIP6 bootstrapping

1. home agent discovery
2. home address configuration
3. security association setup
4. DNS update for the MN

draft-ietf-mip6-bootstrapping-split and
draft-ietf-mip6-bootstrapping-integrated-dhc differ only
on 1). the solutions for 2), 3) and 4) are the same in
both drafts.

 > So, personally, I am a little afraid how all

we have some text on this in the integrated draft. the
mobile node could be configured to use either DHCPv6 or
DNS for HA discovery. based on the configuration the MN
uses a particular mechanism for HA discovery. in case
both are available and the MN gets a response through
a DHCP reply and DNS reply, the DHCP response has
precedence. do you see a need for more text on this? let
us know if there are any issues we havent considered.

> complexity in a deployement architecture.

for NEMO, in addition to the 4 problems listed above, a
mobile network prefix needs to be configured. for that
there are two drafts being progressed in the NEMO WG.

http://www.ietf.org/internet-drafts/draft-ietf-nemo-dhcpv6-pd-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-nemo-prefix-delegation-00.txt

these drafts were written up even before the boostrapping
work started in the MIP6 WG. is there anything else that
needs to be addressed for NEMO bootstrapping?

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 14:13:53 +0200

In your previous mail you wrote:

=> PANA is not in the I-D, i.e., the protocol between the MN and
the NAS is not specified (but it can be PANA).

=> I don't believe it is a real issue, or to use another argument,
you have already the issue for the network access control itself.

=> we can classify mechanisms into mechanisms with a NEMO flag (ICMP-based
DHAAD for instance) or NEMO knowledge (HA-switch for instance), and
zero-knowledge mechanisms where the NEMO knowledge has to be out of band.
I believe it is the case today for DHCP (but it can be easily fixed)
and IKEv2 HA-assignment (where IMHO it is harder without another anycast
address). I can't see a reason to get really different mechanisms for
MIPv6 and NEMO.

Regards

[email-masked]

PS: I'll do a second answer with my comments about the draft (i.e.,
I'll keep the subject and the subject header).

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 14:46:59 +0200

This is a review of draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt:

 - in fact the document can (should?) be split into 2 parts:
   the AAA stuff and the DHCP stuff. IMHO the important part
   is the AAA one because it comes directly from the "integrated"
   scenario, DHCP is used only to transmit the AAA results to
   the MN. One can use in some cases the access control protocol,
   for instance if it is 802.1X.

 - DHCPv6 has some constraints which are not explained in
   the document (cf my previous messages)

 - I don't know if the OPTION_MIP6-RELAY-Option is necessary, i.e.,
   why not use the RADIUS-RELAY-Option (aka RRAO) ?
   (cf. draft-ietf-dhc-v6-relay-radius-01.txt)

 - Security Considerations reference RFC which are not for DHCPv6,
   i.e., the right reference is RFC 3315.

 - DHCPv6 security doesn't work well in multi-domain environments
   so in the mobility context. Quoting RFC 3118:

   The "delayed authentication" protocol does not attempt to address
   situations where a client may roam from one administrative domain to
   another, i.e., interdomain roaming.  This protocol is focused on
   solving the intradomain problem where the out-of-band exchange of a
   shared secret is feasible.

   and:

      Delayed authentication requires a shared secret key for each
      client on each DHCP server with which that client may wish to use
      the DHCP protocol.  Each secret key has a unique identifier that
      can be used by a receiver to determine which secret was used to
      generate the MAC in the DHCP message.  Therefore, delayed
      authentication may not scale well in an architecture in which a
      DHCP client connects to multiple administrative domains.

 - IMHO this paragraph is not sound:

   The communication between the DHCP client and the DHCP server for the
   exchange of home agent information is security sensitive and requires
   authentication, integrity and replay protection.  Either lower-layer
   security (such as link layer security established as part of the
   network access authentication protocol run) or DHCP security
   [RFC3118] can be used.  The latter approach is only applicable in
   non-roaming environments due to the limited applicability of the DHCP
   security mechanisms.  An adversary that is able to modify home agent
   information can force the mobile node to use a different home agent
   than intended by the MSA.  However, this type of attack can be
   detected by the security mechanism between the mobile node and the
   home agent.

 - to finish the document presents the less aggressive scheme to use
   AAA in MIPv6 bootstrapping, i.e., it only assigns the HA. I have
   a concern about this because AAA is the only practical way to
   attach security properties (i.e., a proof it is not fake) to
   the care-of address so to improve the MIPv6 security.
   Unfortunately the document does nothing for this...

Regards

---

From: Julien Bournelle <[email-masked]>
Date: Wed, 26 Oct 2005 15:26:21 +0200

Hi francis,

 just a comment concerning AAA inline,

On Wed, Oct 26, 2005 at 02:46:59PM +0200, Francis Dupont wrote:

<snip>

>    Unfortunately the document does nothing for this...

 the problem with doing what you proposed is the following:

 - or you have to modified all the MN-NAS protocol (e.g. 802.1X/PANA) to
 support bootstrapping Mobile IPv6

 - or you may use EAP and in this case we have an Applicability problem:
   EAP is not for configuration and EAP may not be in use in the access
   network.

 Julien  

-- 
julien.bournelle at int-evry.fr

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 16:05:26 +0200

<snip>

   

=> a la JFK: we choose to do this and the other things, not because
they are easy... (BTW I prefer faster than in this decade :-).
   
Regards

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 26 Oct 2005 17:50:54 +0300

>       DHCP client connects to multiple administrative domains.

Yes, these are right. But, is there any specifics of the DHCP usage
outlined in this document that relates to the above discussion? Whatever
DHCP security or insecurity exists apply to this usage as well.

>    detected by the security mechanism between the mobile node and the

If you can point out the specific issue, that'd be better.

>    Unfortunately the document does nothing for this...

CoA ownership issue is outside the scope of "MIP6 bootstrapping"
problem.

Alper

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 17:42:19 +0200

In your previous mail you wrote:

   >    so in the mobility context. Quoting RFC 3118:...

=> the document recommends DHCPv6 in a context where its security
can't be insured. IMHO this is a major issue.

   >  - IMHO this paragraph is not sound:

=> s/sound/consistent/?

   >    The communication between the DHCP client and the DHCP server for
   ...
   
=> the paragraph begins by "security sensitive" and "requires".
The proposed solutions are lower-layer security, something which can't
be assumed to be always available, and DHCPv6 security, which doesn't
work well in the context (this is my previous comment). It finishes
by explaining the security in fact doesn't matter: this is both
arguable (security matters soon or late, and HA assignment is more
vulnerable then HA discovery) and not consistent with the
beginning.

   >    I have

=> so we have to find a way to put it inside! Note we have CoA
authentication by a trusted third party, a bit more than ownership.   
   
Regards

PS: this is a bit strange: everybody seem to agree that AAA can provide
many good things and at the result it gives only the very minimum...
Perhaps what is wanted is a HA assignment in IKEv2 (making bootstrapping
current work useless) ? cf my checking message in the IPsec list:
http://msgs.securepoint.com/cgi-bin/get/ipsec-0510/26.html

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 26 Oct 2005 21:22:03 +0300

> can't be insured. IMHO this is a major issue.

Actually, what we tried to say was "secure your DHCP in whatever way you
are securing it." Just because you are carrying an HA information does
not require that the DHCP signaling be more or less secured than what
the operator does normally. 

If you agree to that, and have a better way to capture in the document,
please propose some text.

[For DHCP security, the operator may rely on lower-layer security, or
some other mechanism, e.g., draft-yegin-eap-boot-rfc3118-00.txt, etc.]

> be assumed to be always available, 

Many, if not all, deployments rely on lower-layer security. This is
mostly an architectural issue. DSL operators know that the DHCP is run
over physically-secured lines, hence the current deployments don't
involved DHCP-level security....

> and DHCPv6 security, which doesn't

I see your point. The text is inconsistent.

> authentication by a trusted third party, a bit more than ownership.

Sorry I don't understand. Why do you see this issue as part of the "MIP6
bootstrapping problem", which deals with HA, HoA, MN-HA SA
configuration?

> http://msgs.securepoint.com/cgi-bin/get/ipsec-0510/26.html

Do you mind briefly stating why you think this is better than the DNS
and DHCP-based HA discovery/assignment?

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 26 Oct 2005 12:08:18 -0700

Francis,

>    Unfortunately the document does nothing for this...

can you elaborate on this? the AAAH might never know the
CoA of the mobile node. what needs to be proven regarding
the CoA and to whom?

or do you want a solution where the AAAH stores the CoA
of the mobile node, knowing that the CoA was configured
after the MN was authenticated to the AAAH. and later
you want the HA to check with the AAAH to see if the CoA
is valid?

anyway I think it is outside the scope of the bootstrapping
solutions.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 22:30:32 +0200

=> but it seems the operator does normally not use DHCP...

=> as I've said my first concern is the document should be split between
AAA and DHCP...

=> argh, this draft is already expired... (I've it but we should not
rely on it). IMHO the idea to establish the DHCP shared secret in the
AAA phase is good (and similar to draft-dupont-mipv6-aaa-01.txt...).
You are saying too much or not enough (:-).

   
=> hum, the 802.11 final link is not so secure...
IMHO in the scenario the only local secure mechanism is the network
access control, so it should be used to piggyback things in it or
to derive a shared secret for protection, shouldn't it?

   
=> yes, and I believe the real issue is there is no good and general
way to provide the required level of security.

   > => so we have to find a way to put it inside!

=> because AAA is the only mechanism which can provide a solution.
In the document the only feature provided by AAA+DHCP is HA assignment.
For any person who has worked on MIPv6/AAA stuff this is incredibly
limited.
   
Regards

PS: cf my checking message in the IPsec list:
http://msgs.securepoint.com/cgi-bin/get/ipsec-0510/26.html

=> it is far more general, there is only two constraints:
 - IKEv2 has to be used (but it seems it is already in all bootstrapping
   proposals)
 - the anycast address has to be known (exactly as the current DHAAD).
   Note this is compatible with DNS or DHCP-based discovery: in place
   of giving unicast addresses of servers one can answer with anycast
   addresses of server groups.
I've found only advantages at the exception of the compatibity with
NEMO: a second anycast IID should be assigned for NEMO HAs as there is
no way to distinguish between MIPv6 and NEMO HAs.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 26 Oct 2005 23:53:30 +0200

=> the CoA is an important parameter of the network access control
which is done by the AAAL so the AAAH can check with the AAAL
the CoA (this is what I mean by the AAA procedure can provide
an authentication of the CoA using a trusted third party (which
is the AAAL)).

=> this is one way to provide it but my point of view is more
theorical, i.e., there can be all the needed infos, trusts and
communications.

=> it is not in the goals of the bootstrapping solutions you mean?
I agree but some operators could consider it should be added
(it is a shame to ignore a good property, in particular when it
is a security property).

Regards

---

From: Jari Arkko <[email-masked]>
Date: Thu, 27 Oct 2005 07:55:49 +0300

>an authentication of the CoA using a trusted third party (which
I do not think it makes sense to extend the bootstrapping
schemes to provide AAA-based care-of address verification.
(There might be some interest to look at using access network's
help in such checks, in research mode, but this appears
to be possible without AAA.)

One reason for this is separation of functions. It would
be unfortunate if route optimization depended on
specific form of bootstrapping we performed. What's
more, bootstrapping would have to be performed for
every move to a new care-of address, which would
put bootstrapping on critical path, decrease performance,
and in general do something that the bootstrapping work,
in my opinion, was not intended to do.

Secondly, AAA has significant limitations in the
sense that we can't necessarily assume a world
wide AAA where everything can roam everywhere,
and that all links have AAA. Particularly, correspondent
nodes most likely do no thave AAA. My private home network,
for instance, does not, and my company network
does not roam with anything else. And CNN.COM
has no AAA.

Finally, there does not appear to be any reason for
adding this functionality. We already have RFC 3775
route optimization, which, in my opinion, is sufficient
as far as the security requirements go. Where you
are worried about performance, we already have
improved methods that take the care-of address
check out of the critical path. See draft-arkko-mipshop-cba-cga,
for instance.  No AAA was needed to achieve this
speedup. If you are worried about security, there
are again multiple things that we can do without
AAA. For instance, CGA adds a small amount of
security even for the CGA case, though can not
eliminate the need for the test. The test could,
however, be completely eliminated if we did have
some assistance from the access network and
trust between the access network and the
correspondent nodes. This latter is a much
tougher assumption than we have had so far,
perhaps too tough. But people have looked
at schemes where SEND-like certificates
of address prefixes are used in a global manner.
If you assume this, then you can ask the local
router to give an address assignment certificate,
which can be later used to prove your topological
address is correct - without AAA.

--Jari

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 27 Oct 2005 12:39:53 +0300

Francis,

>    Actually, what we tried to say was "secure your DHCP in whatever
way
> you

OK, you are making another point now....

On that point, I'm guessing you are only considering 3GPP operators,
right? Please also consider 3GPP2 and WiMAX operators. Both are using
DHCP in their architectures.

> You are saying too much or not enough (:-).

You may be right. We shall not get too much into DHCP security. 

> => hum, the 802.11 final link is not so secure...

In most, it is not secure. In some, it is. Security is improving with
11i deployments (at what rate, I don't know). 

Well, anyways. These are again architectural and deployment issues. We
are just carrying yet another configuration parameter with DHCP, that's
it.

> to derive a shared secret for protection, shouldn't it?

If you can elaborate, that'd help me understand what you are suggesting.

> way to provide the required level of security.

There is at least one practical way: relying on the lower-layer
security. That's how the DSL and 3GPP2 operator networks use DHCP. That
seems sufficient. [this is a good discussion for DHC WG]

> For any person who has worked on MIPv6/AAA stuff this is incredibly

MN-HA SA is also generated with the help of AAA. This is not discussed
in this document, but part of the overall solution. For anything else,
like CoA "authorization", I'd say interesting but definitely outside the
scope of the bootstrapping problem space. Let's create another thread
and discuss it.

Alper

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Oct 2005 14:33:59 +0200

=> I disagree: there is no such verification today and even
it is not needed it is always fine to be more secure.

=> how you provide this without AAA?

=> Route Optimization??? We speak about initial MN-HA!

   specific form of bootstrapping we performed. What's
   more, bootstrapping would have to be performed for
   every move to a new care-of address,

=> this is not true. The only limit is the MN must stay in
the same AAA domain (i.e., the integrated scenario applies)
if we want to keep the CoA verification.

=> this discussion is not without a context: we are in
the integrated scenario.

   and that all links have AAA.

=> and DHCPv6 (:-)...

   Particularly, correspondent nodes most likely do no thave AAA.

=> we DON'T discuss about RO!

(I don't answer to other comments which are 100% out of the scope).

Regards

---

From: Jari Arkko <[email-masked]>
Date: Thu, 27 Oct 2005 16:14:01 +0300

>=> Route Optimization??? We speak about initial MN-HA!
Sorry. Maybe I need to read the original thread. Why would
you care about care-of address verification for the initial
MN-HA? Or more to the point, why would you need anything
more for the verification than what we would get from
running a protocol such as IKEv2 between the MN and the
HA? Or is this about the pseudonat attack in IKEv2?

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Oct 2005 15:34:11 +0200

right?

=> no, I live in Europe and I know 3GPP operators won't support
IPv6 soon.

   
=> after reading the DHC WG charter I believe we shall simply
*not* rely on DHCP security!

   
=> I can explain (in fact there is even a message in the list with
a reference to an expired draft proposing this) but I believe now
it is not the proper way. Please forget DHCP security and use
only the lower-link security.
   
   security.

=> IMHO it is the only practical way!

   That's how the DSL and 3GPP2 operator networks use DHCP. That
   seems sufficient. [this is a good discussion for DHC WG]
   
=> I agree: the scenario is not too limited when we add this constraint.

=> fifth (the next one I'll get half of the DT :-)!
It seems the "CoA and AAA" thread is the right one, but in part is
on a closed DT list...

Regards