Subject: [Mip6] about draft-ietf-mip6-bootstrapping-split-00.txt

From: Francis Dupont <[email-masked]>
Date: Tue, 02 Aug 2005 17:29:42 +0200

I have two concerns:
 the configuration service in IKEv2 was copied from DHCP,
 in fact, you should consider it as a lightweight DHCP service.
 - so in 5.3.2 you cannot use it to validate a HoA configured by
   the MN. BTW in the past I tried to add a validation/registration
   service for stateless autoconfed addresses in DHCPv6, it was
   rejected by the DHC WG.
 - at the contrary this service is the right one for DNS update
   (in the reverse tree: as usual the MN should update the AAAA RR
    because it has the trust over its FQDN, and the guy who allocates
    the address should update the PTR because it has the trust over
    this part of the reverse tree. PS: confirmed as the session).

BTW the DNS HA address discovery is so better than DHAAD that I believe
it is time for a DHAAD considered harmful I-D (co-authors?) !

regards

[email-masked]

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Aug 2005 08:46:16 -0700

Francis,

>    service for stateless autoconfed addresses in DHCPv6, it was

We had some discussion with IKE folks on this and they recommended that we
introduce a new configuration option for autoconfiguration, which we did.

So would your objection be handled if we remove the text that says that the
IINTERNAL_IPV6_ADDRESS can also be used to confirm an autoconfigured
address?

            jak

---

From: Francis Dupont <[email-masked]>
Date: Tue, 02 Aug 2005 18:44:37 +0200

=> I believe we should have some discussion with DHCP folks too
because it is possible there is an hidden issue (I don't believe
this but to check is better than to be bitten).

=> my concern would be handled but the problem not solved. And my
second objection (DNS update in IKE, not via BU) assumes CFG_REQUEST be
used with MN configured HoAs too.

Thanks

---

From: "James Kempf" <[email-masked]>
Date: Tue, 2 Aug 2005 10:04:55 -0700

> this but to check is better than to be bitten).

OK, we can check with Ralph.

> used with MN configured HoAs too.

We discussed this and I think one issue is that IKE doesn't require that the
address be defended on the local link, while MIPv6 does. I don't know why
they did this, perhaps they were assuming that it was unnecessary for a
DHCP-like solution. Another is that the HA may reject the BU for some
reason, and then the address would need to be unregistered from the DNS, but
the HA couldn't do that because it would not have the FQDN.

What exactly was the issue you had with having the DNS update done via the
BU?

            jak

---

From: Francis Dupont <[email-masked]>
Date: Wed, 03 Aug 2005 09:07:02 +0200

We discussed this and I think one issue is that IKE doesn't require that the
   address be defended on the local link, while MIPv6 does.

=> this is not a problem for DNS update as it always checks if an RR or
a name already exists, and if it is not required it is not forbidden
(in fact it is a good idea as the client is by definition remote and
cannot defend its addresses on the link).

   I don't know why they did this, perhaps they were assuming that it
   was unnecessary for a DHCP-like solution.

=> I believe they just forgot (they are not specialists of IPv6 at all,
and IPv6 people thought that CFG_REQUEST would never be enough).

   Another is that the HA may reject the BU for some reason,

=> this is not a problem: if the MN gives up it can ask the removal
of the RR and has to close the IKE session (i.e., delete the SAs).

   and then the address would need to be unregistered from the DNS,

=> yes, the PTR needs to be deleted.

   but the HA couldn't do that because it would not have the FQDN.

=> I disagree: first the FQDN is not needed as the PTR is for the address
in the reversed name format, and the FQDN is given for registration
so there is no problem to give it for deregistration too.
Perhaps you think about automatic deregistration when the IKE session
goes down (so my first argument applies)?

=> this is not the job of the MIPv6 code and is clearly the job of the
tool which allocates the HoA: IKE CFG_REQUEST stuff. Here I apply
my idea that IKE CFG_REQUEST is DHCP-like and DNS update is a classical
service offered by DHCP. BTW the DNS update must be secured i.e. the
tools performing it be trusted, so it is not simple...

Thanks

---

From: "James Kempf" <[email-masked]>
Date: Wed, 3 Aug 2005 08:29:43 -0700

> of the RR and has to close the IKE session (i.e., delete the SAs).

If the HoA  configured through IKE is registered with the BU rather than
with the IKE transaction - and the HA rejects it - the MN can keep up the SA
and do mobile prefix discovery within the SA, then send a BU for a newly
autoconfigured address. The HA will then DAD it. So I don't think the SA
needs to be taken down if the address is rejected, unless it is for some
reason the SA identifier (which of course it shouldn't be in the MIP case).

I think to be able to do DNS within the IKE transaction, the VPN tunnel
endpoint would have to DAD the address. I suppose we could specify DAD as
part of the new IKE config option we'll be requesting but we would also need
to include a DNS config option within IKE too for this purpose.

> goes down (so my first argument applies)?

No, I was thinking that the HA would have to cache the FQDN between the
close of the IKE transaction and the BU transaction. I think this might be
awkward from an implementation perspective.

> tools performing it be trusted, so it is not simple...

Well, if the IKE-configed address gets rejected and the MN configs a new
address through prefex discovery and the BU, the HA will have to do the DNS
update anyway, so it seems like it might be a good idea to have that
capability in any event.

            jak

---

From: Francis Dupont <[email-masked]>
Date: Thu, 04 Aug 2005 09:52:31 +0200

> of the RR and has to close the IKE session (i.e., delete the SAs).

=> note that by to give up I really mean to give up, not to retry
with another HoA. BTW in this case we have to explain what happens
to the previous HoA, even when it was allocated by IKE CFG_REQUEST,
so this cannot be used as an argument in favor (or against) registering
by BU.
   
   If the HoA  configured through IKE is registered with the BU rather than
   with the IKE transaction - and the HA rejects it - the MN can keep up the SA
   and do mobile prefix discovery within the SA,

=> MPD is a junk function: renumbering time scale is in months and
the mobile prefix is likely discovered by DNS or something like.
BTW I'd like to know how you can get the HA address without the prefix (:-).

   then send a BU for a newly
   autoconfigured address. The HA will then DAD it.

=> I believed you'd like to do allocation or validation in IKE CFG_REQUEST
in order to avoid the DAD... But even it is not part of the whole idea,
we should agree that to try another address needs to change the SA pair
before so this can always be done with some IKE interaction.

   So I don't think the SA
   needs to be taken down if the address is rejected,

=> perhaps for the IKE SA but the IPsec SA pairs must be changed.

   unless it is for some
   
=> so you are talking about the IKE SA

   I think to be able to do DNS within the IKE transaction, the VPN tunnel
   endpoint would have to DAD the address.

=> not necessary but IMHO I am in favor of this.

   I suppose we could specify DAD as
   part of the new IKE config option we'll be requesting but we would also need
   to include a DNS config option within IKE too for this purpose.
   
=> I can't see a problem here: DNS update is a well known service offered
by DHCP so in the idea of IKE CFG_REQUEST.

   No, I was thinking that the HA would have to cache the FQDN between the
   close of the IKE transaction

=> what is the close of the IKE transaction?

   and the BU transaction. I think this might be
   awkward from an implementation perspective.
   
=> I don't understand...

   update anyway,

=> the MIPv6 code or the IKE code on the HA? As I've explained both will
be involved.

   so it seems like it might be a good idea to have that
   capability in any event.
   
Regards

---

From: Vijay Devarapallli <[email-masked]>
Date: Thu, 4 Aug 2005 07:16:59 -0700

hi Francis,

> tools performing it be trusted, so it is not simple...

there are two issues. first, this would mean he MN is not in control of 
the DNS update. the HA does it everytime it replies with a HoA in a 
CFG_REPLY message. not sure thats a good idea. in some cases, 
the MN may not want the HoA published in the DNS. it would be 
good to get an indication from the MN before doing the DNS update.
second, we want to support HoA auto-configuration (RFC 2462, RFC 
3041, CGA). when the MN autoconfigures a HoA, we dont use 
CFG_REPLY. the HA doing the update when it sends CFG_REPLY
message supports only assigned HoA.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Thu, 04 Aug 2005 16:30:29 +0200

CFG_REPLY message.

=> no, the MN asks the HA to update the reverse tree. The discussion is
about where to put the DNS updater code (IKE or MIPv6).

   not sure thats a good idea. in some cases, 
   the MN may not want the HoA published in the DNS.

=> of course it will be done at the request of MN. We can even imagine
ways where only a bit is enough. IMHO we need a new CFG_REQUEST (SET?)
with an optional parameter to carry the MN's FQDN if it is not yet
available (in the CERT or ID for instance).

   it would be 

=> we agree

=> I can't parse everything here but my proposal is based on a
positive answer (which are still waiting for) about a new "validation"
service from the IKE CFG_REQUEST stuff.

Regards

---

From: Vijay Devarapallli <[email-masked]>
Date: Thu, 4 Aug 2005 09:00:54 -0700

> about where to put the DNS updater code (IKE or MIPv6).

putting it in IKE means, we need to modify CFG_REQUEST to include
an indication from the MN. IMHO, we should avoid that.

then there is the authentication option protocol. IMO, we should eventually
have a bootstrap solution for the authentication option protocol too. an
IKE specific extension for the MN indication might not work when the
authentication option protocol is used. so its better to put the indication
in the binding update.

> service from the IKE CFG_REQUEST stuff.

I was talking about HoA auto-configuration which is slightly different
from HoA assignment. in the former, the home prefix is obtained first,
the MN auto-configures the HoA and then sets up security 
associations using CREATE_CHILD_SA exchange. in the latter,
HoA is assigned during the CFG_REQ/CFG_REPLY exchange.

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Thu, 4 Aug 2005 09:15:15 -0700

> about where to put the DNS updater code (IKE or MIPv6).

Are we only talking about the reverse tree here? That case is less
interesting, since, AFIKT from talking with DNS folks the reverse tree is
not well maintained.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 4 Aug 2005 09:26:10 -0700

> BTW I'd like to know how you can get the HA address without the prefix
(:-).

Remember we are dealing with IPv6 here and the home link could have multiple
prefixes. Now why exactly the MN might want to select one prefix over
another is a different question.

> => what is the close of the IKE transaction?

Sorry, I meant during the IKE_AUTH or CREATE_CHILD_SA. The address
configuration could occur during either. If the former, then there would be
an issue with doing another address under the IKE SA, I would think.

>    awkward from an implementation perspective.

The HA would have to maintain the FQDN in some kind of table accessable to
the IKE code and the MIP code, so that MIP could remove the DNS PTR if the
BU failed.

> => the MIPv6 code or the IKE code on the HA? As I've explained both will

If the MN autoconfigs the address after the IKE_AUTH/CREATE_CHILD_SA is done
and while it is doing the BU, then the MN may want the HA to do the DNS
update.

            jak

---

From: Francis Dupont <[email-masked]>
Date: Thu, 04 Aug 2005 18:38:55 +0200

=> CFG_REQUEST is already modified to add the MPD stuff and the validation
function.

   then there is the authentication option protocol.

=> the thing the 3GPP2 will drop as soon as it will discover it will
stay informational for ever (:-)?

   IMO, we should eventually have a bootstrap solution for the
   authentication option protocol too.

=> my opinion is simple: the tool in charge of the (optional) allocation
of the HoA should be in charge of the DNS update in the reverse tree.

   an IKE specific extension for the MN indication might not work when the
   authentication option protocol is used. so its better to put the indication
   in the binding update.

=> note that my argument works even when there is no security at all
as it is today I am afraid...

   from HoA assignment.

=> the draft begins with assignment and extends things with auto-config.
IMHO this is not a silly idea.

   in the former, the home prefix is obtained first,

=> or the home agent address is obtained first and the home prefix is
taken from it.

   the MN auto-configures the HoA and then sets up security 
   associations using CREATE_CHILD_SA exchange.

=> in the middle the I-D adds a validation phase using the CFG_REQUEST.
This was my first concern as this validation function is not standard
in DHCP (the model of the CFG_REQUEST services).

   in the latter,
   
Regards

PS: BTW if you talk about authentication the tool which performs it
is IKE and it is the only tool which can check if the MN is presenting
a fake FQDN, i.e., DNS update by IKE CFG_REQUEST has a small security
advantage over any other solution, in particular over solutions which
are not bounded to authentication/authorization.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 04 Aug 2005 18:43:14 +0200

> about where to put the DNS updater code (IKE or MIPv6).
   
   Are we only talking about the reverse tree here?

=> yes, remember: I asked during the session two days ago.

   That case is less interesting, since, AFIKT from talking with DNS
   folks the reverse tree is not well maintained.
   
=> I agree. The question to simply drop the reverse tree for IPv6 is
still open.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 04 Aug 2005 19:08:15 +0200

=> we'll talk about this tomorrow but today the home agent address is in
the home prefix. I even believe some implementations verify this...

   
=> the IKEv2 draft explains the CFG_REQUEST should only fail with
an error notification for hard errors like bad format. So retries
seems to be acceptable.

   
=> I disagree but what happens when things are finished is not clearly
defined. IMHO when the IKE SA is closed:
 - IPsec SAs are closed (IKEv2 management of SAs)
 - PTR RR is deleted by DNS update (and as a side effect the name can be
   deleted too)
 - allocated HoA is returned to the pool
 - (MIP interaction) BCE is deleted, proxy ND disabled
If you'd like to expire allocated HoAs only at their term (DHCP supports
both style), the PTR RR should be deleted at this moment. IMHO the first
style does a better usage of the pool but both work.

=> so the IPsec SAs are not established with the new address???

=> look at my last "killing" argument: the entity doing the authentication/
authorization is in a better place to verify the FQDN. Don't forget that
in fact the only info of this kind the MIPv6 code has is about the HoA,
for instance you can change the CoA between IKE and the BU in theory.

Regards

---

From: "James Kempf" <[email-masked]>
Date: Thu, 4 Aug 2005 10:23:11 -0700

Francis,

> in DHCP (the model of the CFG_REQUEST services).

I asked Ralph whether the IKEv2 folks had consulted the DHCP WG on the
config and he said no. Perhaps there was some discussion amongst themselves
on this, but he hadn't heard of it. So it is not clear to me that the IKEv2
folks used any specific model of address configuration.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 4 Aug 2005 23:54:16 -0700

> => so the IPsec SAs are not established with the new address???

We talked about having the MN autoconfig an address if it needed it during
the MIP transaction, but you bring up a good point. The MN would need to go
back and redo the CREATE_CHILD_SA with the address before registering it, to
make sure IKE knew about it. We should say something about that in the
document

> for instance you can change the CoA between IKE and the BU in theory.

But after CREATE_CHILD_SA, the HA has a link to an authorized NAI through
the IPsec SA SPI for the MN. So, in theory, the HA could use that to check
the authorization (in fact, we probably should have stated that in the
document).

            jak