Subject: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-split-01 - IPv2/CFG

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Dec 2005 02:29:24 +0100

The MIP6_HOME_PREFIX stuff is very questionable: the IKEv2 CFG facility
is not designed to be or become a general configuration facility.
In particular a CFG address payload is always included into an IKE_AUTH
(section 2.19) so the idea to get the home prefix with a IKE_AUTH without
creating a CHILD_SA is out of the spec. I am afraid the INTERNAL_IP6_ADDRESS
(there is a typo with IP6_INTERNAL_ADDRESS page 14) is the only allowed
way so the home prefix length should be configured (to 64 bits by default)
and MPD used to discover home prefixes.
There is a second very unclear usage of the MIP6_HOME_PREFIX and the
error (???) USE_ASSIGNED_HoA. The home prefix length included in
INTERNAL_IP6_ADDRESS replies should be enough?

Last point, if the IKEv2 CFG stuff is not enough (I can understand
this opinion) we can try to reactivate the DHCP over IKEv2 work.
This stands for NEMO (which needs the whole DHCPv6 Prefix Delegation
facility) too.

Regards

[email-masked]

PS: note that to define a new CFG attribute is "by expert review" so
should be avoided.

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 Dec 2005 18:01:43 -0800

Francis Dupont wrote:

> error (???) USE_ASSIGNED_HoA. 

this basically allows the HA to deny HoA auto-configuration
and force the mobile node to use an assigned HoA.
USE_ASSIGNED_HOA is a new notification payload we want to
standardize.

> this opinion) we can try to reactivate the DHCP over IKEv2 work.

best of luck with this. probably needs a new BOF. :)

> PS: note that to define a new CFG attribute is "by expert review" so

we were going to get it reviewed by IPsec experts. or has it
already been done? Gerardo?

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Dec 2005 05:23:45 +0100

=> argh! It is clearer now. I don't believe the issue is particular
to mobility so at least the names are not good. The INTERNAL_IP6_ADDRESS
can be set by the MN to a requested address so the new error is not
needed if we simply require that the MN always puts its auto-configed
HoA in an INTERNAL_IP6_ADDRESS and the HA raises a FAILED_CP_REQUIRED
when it doesn't (i.e., we require the CFG stuff on the MN side).

I can't see what is the use of MIP6_HOME_PREFIX and why already
existing CFG_REQUESTs are not enough...

   
=> it could be important for the future of IPv6. We should get
help from all IPv6 guys.

Regards

---

From: "James Kempf" <[email-masked]>
Date: Wed, 7 Dec 2005 13:18:54 -0800

Francis,

We asked Pasi about using the existing IKE CFG options during the DT 
discussions, for example, whether we could use INTERNAL_IPV6_SUBNET to get 
the prefixes, and he said we should define a new CFG attribute. That's why 
we put MIP6_HOME_PREFIX into the draft.

Regarding use of MPD, as you and Vijay describe in 
draft-ietf-mip6-ikev2-ipsec-04.txt (now in AD Evaluation), the IPsec SPD 
entries for the MPD solicitations require the home address to be known, so 
there is a bootstrapping problem here, which is what this draft is all 
about. The MPD could not be done with the IKE SA because the home address is 
not known at that point. The MN would have to request a tentative home 
address from the HA, then later, when it contacted the HA, it would have to 
perform the MPD and autoconfigure an address. This seems like an extra bit 
of overhead that is unnecessary, since IKE already has the ability to 
configure addresses. Or were you proposing to modify 
draft-ietf-mip6-ikev2-ipsec-04.txt in order to allow MPD during the 
CREATE_CHILD_SA?

Regarding using DHCP during IKE, RFC 3456 describes how to do this for IKEv1 
and I am told that it has not been deployed. I don't know the reasons, but I 
have also heard that one of the reasons robust support for address 
configuration was put into IKEv2 was because RFC 3456 was not acceptable. 
Therefore, I believe it would be a mistake to try to define some way to do 
DHCP within IKEv2, since it seems people have already rejected it.

Finally, if you don't like the names we can change them. I actually would 
prefer something a little more generic myself.

            jak

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Dec 2005 12:37:03 +0100

=> INTERNAL_IP6_SUBNET? This seems more a candidate for a headache
if you try to understand what it is for...

=> but do we need prefixes at bootstrapping time?

   not known at that point.

=> yes, MPD is usable after the initial home registration so I agree
it is not part of bootstrapping.

   The MN would have to request a tentative home 
   address from the HA, then later, when it contacted the HA, it would have to 
   perform the MPD and autoconfigure an address.

=> this is not a good idea.

   Or were you proposing to modify 
   draft-ietf-mip6-ikev2-ipsec-04.txt in order to allow MPD during the 
   CREATE_CHILD_SA?
   
=> if we add something over IKE it will be more DHCPv6 than MPD!

   Regarding using DHCP during IKE,

=> my position is clear:
 - there should be not mobility specific stuff in IKE CFG
 - DHCPv6 is already a complete solution for the generic case
   (so applying the previous clain it is a complete solution for mobility too)
 - if something is needed in the delta between IKE CFG and DHCP we have
   to consider to add it to IKE CFG or (better but harder) to jump to
   DHCPv6 over IKE.

   RFC 3456

=> this is DHCP over IPsec.

   describes how to do this for IKEv1 
   and I am told that it has not been deployed. I don't know the reasons,

=> just because DHCP over IKE is far better with a pretty small drawback:
the spec was never finished.

   but I 

=> yes, there were many discussions about the 3 solutions:
 - CFG stuff
 - DHCP over IPsec (aka RFC 3456)
 - DHCP over IKE
The first one was far easier and as IPv6 people didn't shout it was too
limited it was adopted. DHCP over IKE was very promising but complex
so it was postponed.

=> it was not rejected but there was a choice to do between something
not perfect but immediately available and something far more promising
but available only in a further future.

=> what do you think about by proposal for USE_ASSIGNED_HoA replacement?
About the MIP6_HOME_PREFIX, what I've understood about it is the MN
wants to know a home prefix to form its home address.
Not considering the issue about the home prefix length (which will be
in 99.99% of cases 64), the MN doesn't need to know the home prefix
because it can:
 - propose a full home address (i.e., "please give me again the last one")
 - propose an interface ID (i.e., "please fill the prefix")
 - propose an empty address (i.e., "pleave give me any address")
So we have a solution for all cases in one exchange (the last point,
one exchange, is important because IKEv2 supports only it).
Note the INTERNAL_IP6_ADDRESS attribute both an address and
a prefix length, so the CFG_REPLY always contains a home prefix.
So is it too late? And if yes why?

Regards

PS: we have to consider also NEMO, in particular about the CFG stuff vs.
DHCPv6 over IKE question.
PPS: the IKEv2 I-D 17 quote:

      o  INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
         internal network, sometimes called a red node address or
         private address and MAY be a private address on the Internet.
         In a request message, the address specified is a requested
         address (or zero if no specific address is requested). If a
         specific address is requested, it likely indicates that a
         previous connection existed with this address and the requestor
         would like to reuse that address. With IPv6, a requestor
         MAY supply the low order address bytes it wants to use.
         Multiple internal addresses MAY be requested by requesting
         multiple internal address attributes.  The responder MAY only
         send up to the number of addresses requested. The
         INTERNAL_IP6_ADDRESS is made up of two fields; the first
         being a 16 octet IPv6 address and the second being a one octet
         prefix-length as defined in [ADDRIPV6].

         The requested address is valid until the expiry time defined
         with the INTERNAL_ADDRESS EXPIRY attribute or there are no
         IKE_SAs between the peers.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 8 Dec 2005 09:57:50 -0800

Francis,

> if you try to understand what it is for...

Well, what *is* it for then? The IKEv2 draft is very unclear on this point. 
I had thought it was for the purpose of allowing the IKEv2 initiator to 
autoconfigure an address in the VPN subnet. The DT was told by  the IKEv2 
people that this is not the case, but never got a clear answer about how it 
was intended to be used.

> => but do we need prefixes at bootstrapping time?

Yes, if you want to autoconfigure a home address that is a CGA or a privacy 
address. I know that secure proxy ND is not yet defined, but we have a few 
possible approaches to it, and I and some other folks think that we could 
get a standard on it. And privacy addresses are defined.

> - there should be not mobility specific stuff in IKE CFG

Do you oppose the Mobike extensions? Mobike defines two new CFG options, 
ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS. I have not seen you make 
any case against them on the Mobike list.

Regarding the CFG options proposed in the split document, I am certainly in 
favor of defining them broadly enough that they can be used outside of 
mobility, if that is possible. For example, I see no reason why a fixed node 
might not want to autoconfigure a CGA or privacy address on the VPN network.

> => this is DHCP over IPsec.

Thanx for the correction.

> but available only in a further future.

This is a curious argument. From this history, it sounds as if the IKE 
community has rejected DHCP over IKE. Why do you think that the MIP6 WG 
would have any more success if it tried to standardize it? I would assume 
that the Security Directorate would reject that approach when the document 
is reviewed.

> => what do you think about by proposal for USE_ASSIGNED_HoA replacement?

Sounds fine to me.

> - propose an empty address (i.e., "pleave give me any address")

The DT discussed all these. We decided that;
- the MN can't propose a full home address because the HA might be different 
from the last one. Even if the HA is the same, the HA may route more than 
one subnet, and the MN might want to select a different subnet, for privacy 
or other reasons.
- Again, the MN may want to select a different subnet prefix,
- The MN may want to use a CGA or privacy address,

Note that if the MN wants to use a CGA, it must know the subnet prefix 
beforehand, because that is used in the CGA calculation.

> So is it too late? And if yes why?

Yes, the DT considered that too. While this would work for privacy 
addresses, it would not work for CGAs because the subnet prefix is used in 
the CGA calculation.

            jak

---

From: Francis Dupont <[email-masked]>
Date: Thu, 08 Dec 2005 20:16:54 +0100

Well, what *is* it for then? The IKEv2 draft is very unclear on this point. 
   I had thought it was for the purpose of allowing the IKEv2 initiator to 
   autoconfigure an address in the VPN subnet.

=> it is not as it is a subnet (aka a prefix).

   The DT was told by the IKEv2 people that this is not the case, but
   never got a clear answer about how it was intended to be used.

=> there is something in the clarification document but IMHO it is
not a clarification at all.

   address.

=> I disagree, you can propose the interface ID which should be accepted
as a collision has a probability of zero. BTW the privacy address stuff
was not understood so someone proposed to remove this possibility (:-)
but this was fixed by the few IPv6 people reading the IPsec list.

   I know that secure proxy ND is not yet defined, but we have a few 
   possible approaches to it, and I and some other folks think that we could 
   get a standard on it. And privacy addresses are defined.
   
=> I agree: it is very important to be allowed to propose the interface ID.
But you don't need to know the home prefix before, only its length,
and as it will be 64 bits you don't need to know something...

   Do you oppose the Mobike extensions? Mobike defines two new CFG options, 
   ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS.

=> MOBIKE defines new notifications, including two with these names.
It doesn't define new CFG attribute (no need) nor new payload
(more questionable).

   I have not seen you make any case against them on the Mobike list.

=> no, MOBIKE is chartered to do that.
   
   Regarding the CFG options proposed in the split document, I am certainly in 
   favor of defining them broadly enough that they can be used outside of 
   mobility, if that is possible.

=> I share this idea!

   For example, I see no reason why a fixed node might not want to
   autoconfigure a CGA or privacy address on the VPN network.

=> it is so true that the mechanism for doing that is already available!

   This is a curious argument. From this history, it sounds as if the IKE 
   community has rejected DHCP over IKE.

=> to choose an alternative is not as strong as to reject.

   Why do you think that the MIP6 WG would have any more success if it
   tried to standardize it?

=> it is not in its scope but if the MIP6 WG shows a good real world
case where DHCP over IKE can't be round around we have a good chance
(BTW it will be fine to get a generic (i.e., not bound to mobility) case).

   I would assume that the Security Directorate would reject that
   approach when the document is reviewed.

=> I can't see why, DHCP over IKE is likely to be at least as secure as
the current CFG stuff.

   Sounds fine to me.
   
=> fine, I don't need to convince you that the less new things we have
in the scope of other WGs the best we'll be.

   The DT discussed all these. We decided that;
   - the MN can't propose a full home address because the HA might be
     different from the last one.

=> it is an issue for the HA and it can accept or reject, exactly as
DHCPv6 can use the proposed address or assign another one. I don't
believe you want to forbid this, you just believe we can't rely on it.

     Even if the HA is the same, the HA may route more than one
     subnet, and the MN might want to select a different subnet, for
     privacy or other reasons.

=> but the only way to select a different subnet is to get the list
of all home subnets. The split draft says explicitely "one prefix".
I've missed something...

=> even DHCPv6 doesn't provide this feature. I am nearly convinced
we need a home prefix discovery mechanism (obviously with the
help of the DNS)...

   
=> a way to send the CGA parameters will be fine too (I vote for
a new CERT payload encoding).

   
=> so the only real issue is with the CGA? With the CGA parameters the
allocator can compute itself the interface ID so perhaps we can solve this
case too? Note that the collision count makes more sense on the allocator
in this case because it can check collision at the opposite of the MN
(argh! I've found a new argument to perform the proxy DAD in IKE :-).
As the CGA issue seems to be solved independently I suggest to open
a new thread in another list (is one of our area directors here? :-)

Thanks

---

From: "James Kempf" <[email-masked]>
Date: Thu, 8 Dec 2005 13:13:08 -0800

> a new thread in another list (is one of our area directors here? :-)

Yes, that's the primary *technical* issue.

I suppose it would be possible to define a new IKE CFG option, 
INTERNAL_IPV6_CGA_ADDRESS_REQUEST, or something like that. But it really 
doesn't feel right architecturally. CGAs (at least the single key kind) are 
supposed to be autoconfigured by the owner of the RSA key, not another 
party.

In order to do allow the IKEv2 responer to configure the CGA, the requestor 
would have to send the CGA parameters to the responder. These are the CGA 
RSA public key, the modifier, and the SEC parameter. The IKEv2 responder 
would have to send back the address, the number of bits in the subnet prefix 
or the subnet prefix itself, and the DAD collision count before the address 
was confirmed. Alternatively, the IKEv2 responder could select the modifier 
and the SEC parameter and send them back too.

And also, it would not support allowing the MN to itself configure privacy 
addresses. I know that one can do this already with IKEv2 by sending the 
interface identifier and I know that the current MIP6_HOME_PREFIX doesn't 
support more than one prefix,  but it seems to me it would be a lot more 
general to define a CFG option such as INTERNAL_IPV6_PREFIX_LIST, and have 
the CFG option return a list of IPv6 prefixes instead of one. That gets 
around all the mess of having to exchange the CGA parameters. It is a more 
general solution, because it covers more than just CGAs. What if someone 
comes up with another clever way for a node to define interface identifiers 
(in fact, I've heard that the SHIM6 WG is proposing just that, and I believe 
it involves hashing the interface identifiers together)? With a general 
solution, another IKEv2 CFG option would not need to be introduced.

Incidently, please note that if CGAs are used, the IKEv2 responder does, in 
fact, need to DAD the address, since the IKEv2 initiator needs a collision 
count in order to form the address. If a generic prefix return option is 
used, the IKEv2 initator can form the address, propose it to the responder, 
increment the collision count if the address is rejected, then form and 
propose another address.

But there is a more important *process* issue here. Does the MIP6 group want 
to have the bootstrapping draft to be held up on an as-yet-unwritten (and, 
in fact, un-agreed-to-write) draft from another as-yet-unidentified working 
group? I think we really need to answer that question too. And, for that, I 
think we need the advice of the ADs and WG chairs.

            jak

---

From: Francis Dupont <[email-masked]>
Date: Fri, 09 Dec 2005 01:07:06 +0100

=> I'd like the CGA idea and I should support you but here we ask
something which is not supported (yet) by DHCPv6 for instance
so it is not a surprise we have some trouble... We need a generic
solution which can be applied in one exchange (it is required for
IKE CFG stuff and DHCPv6 in "rapid commit").

   I suppose it would be possible to define a new IKE CFG option, 
   INTERNAL_IPV6_CGA_ADDRESS_REQUEST, or something like that.

=> as the parameters are to be transmitted I believe we have to
go further than the IKE CFG model.

   But it really doesn't feel right architecturally. CGAs (at least
   the single key kind) are supposed to be autoconfigured by the owner
   of the RSA key, not another party.

=> I disagree: the last step of the generation can be done by anybody.
In fact, they have to be done to check the generation itself.
We just exchange the roles but this has no impact on the security
features.
   
   In order to do allow the IKEv2 responer to configure the CGA, the requestor 
   would have to send the CGA parameters to the responder.

=> yes and I believe it has to do this anyway. As it is a crypto stuff
IMHO a CERT payload is a better place.

   These are the CGA  RSA public key, the modifier, and the SEC parameter.

=> the SEC parameter is not in the CGA parameters but in top bits of
the interface ID. It can be taken from it or from Hash2.

   The IKEv2 responder would have to send back the address, the number
   of bits in the subnet prefix

=> CGAs require a 64 bit prefix

   was confirmed.

=> after the address is confirmed (BTW I don't believe it is necessary to
send the collision count which can only get 3 values, the address contains
all other infos and the collision count can be taken from it in at most
3 tries).

   Alternatively, the IKEv2 responder could select the modifier 
   and the SEC parameter and send them back too.
   
=> I disagree about the SEC parameter: it has to be controlled by the
requestor.

   addresses.

=> I don't understand this statement which says the opposite of the next one.

   I know that one can do this already with IKEv2 by sending the 
   interface identifier and I know that the current MIP6_HOME_PREFIX doesn't 
   support more than one prefix,

=> this is why I didn't understand the MIP6_HOME_PREFIX.

   but it seems to me it would be a lot more 
   general to define a CFG option such as INTERNAL_IPV6_PREFIX_LIST, and have 
   the CFG option return a list of IPv6 prefixes instead of one. That gets 
   around all the mess of having to exchange the CGA parameters.

=> we need to exchange the CGA parameters to have a proof of ownership.

   It is a more  general solution, because it covers more than just CGAs.

=> but only the CGAs require it and the CFG stuff is limited to
an exchange only.

   What if someone 
   
=> this is why I believe we need a home prefix discovery as we'll have
the same problem if we change IKEv2 CFG for another thing.

   Incidently, please note that if CGAs are used, the IKEv2 responder does, in 
   fact, need to DAD the address, since the IKEv2 initiator needs a collision 
   count in order to form the address.

=> yes, I am not happy with this.

   If a generic prefix return option is used, the IKEv2 initator can form
   the address, propose it to the responder,
   increment the collision count if the address is rejected, then form and 
   propose another address.

=> I believe you forget the CFG stuff is done in one exchange (cf
draft-ietf-ipsec-ikev2-17.txt at the top of page 79).

=> a home prefix discovery should not have this kind of problems...
We can use directly (i.e., MSP name -> infos) the DNS only all HA
serve the same prefixes, so we have to attach the info to HA names.

Regards

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 09 Dec 2005 11:55:53 +0900

Hi James and Francis,

Please find my comments inline:

On Thu, 8 Dec 2005 13:13:08 -0800

> Yes, that's the primary *technical* issue.

I found this interesting.

> solution, another IKEv2 CFG option would not need to be introduced.

I agree with your statement that general solution (IRAC consults IRAS
for available prefixes) would be useful.  If a node (IRAC) consults
the SGW (IRAS) for a set of prefixes, it can just autoconfigure (by 2462,
CGA, HBA or whatever) its own address.  And as you mentioned, there is a
proposal in SHIM6 WG which specifies a mechanism for generating crypto
locators (HBA).  If we let IRAS do intelligent address allocation, we
may need to define options for each method, which would make IKEv2 more
complex.

> increment the collision count if the address is rejected, then form and 

You are right. I see the latter case (initiator configures its own
address) is simpler.  With option 1 (the solution for proxy DAD on HoA),
the MN can be informed of the address collision by receiving BA with
status code indicating that collision occurred with the claimed address.
Then the MN will retry with different address by incrementing the
collision count.

> think we need the advice of the ADs and WG chairs.

While I am feeling that the above issue (how can CGA be allocated for a
node in IKEv2 scenario) is going beyond the scope of MIP6 WG, I also
think that the MIPv6 WG should formulate the requirements for IKEv2
indicating which technical components are missing etc.

Regards,
Shinta

---

From: "James Kempf" <[email-masked]>
Date: Fri, 9 Dec 2005 09:04:24 -0800

Sugimoto-san

Yes, this makes the most sense to me. Have a generic CFG option that returns 
all the IPv6 prefixes for the HA/VPN gateway, not just one. This can be used 
by any address autoconfiguration algorithm on the IRAC. I don't think the 
idea of advertising the prefixes in the DNS will be acceptable for standard 
VPN gateway use, though it might for Mobile IP use. Most enterprise 
sysadmins I've known would not accept a solution that publicized the 
internal topology of their VPN-protected network. So a CFG option that 
returns prefixes is more generic as it would apply for both MIP and VPN use.

Regarding where it should be done, I feel we should ask the ADs and WG 
chairs about it. Since the IPsec WG is closed, I do not see a WG which could 
quickly get this option standardized, and we do need standardization to 
proceed apace with the bootstrapping draft. Therefore, I think it would be 
best to put it into the split draft, unless the ADs and WG chairs feel 
otherwise.

            jak

----- Original Message ----- 
From: "Shinta Sugimoto" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Francis Dupont" <[email-masked]>; <[email-masked]>; 
"Vijay Devarapalli" <[email-masked]>
Sent: Thursday, December 08, 2005 6:55 PM
Subject: Re: [Mip6] WGLC: draft-ietf-mip6-bootstrapping-split-01 - IPv2/CFG

---

From: Francis Dupont <[email-masked]>
Date: Fri, 09 Dec 2005 23:01:14 +0100

Yes, this makes the most sense to me. Have a generic CFG option that returns
   all the IPv6 prefixes for the HA/VPN gateway, not just one. This can be used
   by any address autoconfiguration algorithm on the IRAC.

=> the problem is the MN has to register a temporary address and to
come again with the auto-configured one. So IKEv2 CFG is not the right
mechanism.

   I don't think the 
   idea of advertising the prefixes in the DNS will be acceptable for standard 
   VPN gateway use, though it might for Mobile IP use. Most enterprise 
   sysadmins I've known would not accept a solution that publicized the 
   internal topology of their VPN-protected network.

=> this is an issue when the internal network is really internal but
the situation is reversed in Mobile IP.

   So a CFG option that returns prefixes is more generic as it would
   apply for both MIP and VPN use.
   
=> but it needs to transform the CFG mechanism in a real negociation
which is explicitely forbiden in the IKEv2 specs.

=> I don't believe the IPsec community will accept such major change.
IMHO it will be easier and more efficient to reactivate the DHCP over
IKE... In fact the best is to contact the NEMO WG to decide if the
DHCP over IKE will be necessary or if we can live with a lighter
weight solution.

Regards