Subject: RE: [Mip6] Bootstrapping on the home link

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 13 Apr 2006 12:24:53 -0700

> -----Original Message-----
> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Thursday, April 13, 2006 12:14 PM
> To: Vijay Devarapalli; Giaretta Gerardo
> Cc: [email-masked]
> Subject: RE: [Mip6] Bootstrapping on the home link
> 
> Vijay,
> The bootstrapping documents specify some MUSTs for MIP6 bootstrapping
> and also specify recommended behavior of DNS or IKEv2 as 
> applicable for
> MIP6. If we go by the same argument that we can "configure 
> the MN to set
> up an SA as soon as it gets an HA assigned", then, there are 
> other parts
> of the document that should receive similar treatment. For instance,
> going by your argument, what value does the following statements in
> section 9.5 of draft-ietf-mip6-bootstrapping-split add - 
> 
> "A security association is required even if the DNS server is in the
> same administrative domain as the Home Agent. The security association
> SHOULD be separate from the security associations used for other
> purposes, such as AAA."
> 
> One can claim that HA can be configured to say that the SA 
> with the DNS
> server is a separate one. But, the statement is there because 
> we believe
> it is good recommended behavior and hence, should really be 
> part of the
> implementation and not a configuration. 

in this case a MUST is required because it would
be a bad idea for the HA to perform a DNS update
without authenticating itself to the DNS server.
otherwise any malicious node in the home network 
or a mobile node through the tunnel to its HA can 
send a DNS update on behalf of another mobile node.
therefore the 'MUST' is required for securing the
DNS update between the HA and the DNS server. it
is not a configuration issue on the HA in this 
case.

> 
> Please see some specific comments inline below. 
> 
> > 
> > > > > Right, I understand that per RFC3775, the MN is supposed to
> > > > be on its
> > > > > own when it is at home and hence doesn't need an
> > > > IKEv2/IPsec SA. But,
> > > > > in the interest of reducing handoff latency, don't we want to 
> > > > > recommend that the MN set up the SA even if it detected
> > > > being at home?
> > > > 
> > > > its a configuration issue on the mobile node.
> > > > it can setup an IPsec SA with the home agent if it wants to. 
> > > > since the IPsec SA is not tied to the existence of a 
> > binding cache 
> > > > entry, the HA wouldnt reject the MN's request to setup an 
> > IPsec SA.
> > > > 
> > > 
> > > How is this just a configuration issue? This is about the MN 
> > > triggering the set up of an IKEv2 and IPsec SA even when it 
> > knows it 
> > > is home from a
> > > MIP6 perspective - are you saying that MIP6 implementations 
> > must allow 
> > > configuration of this behavior? There is not clear guidance to 
> > > implementors on what triggers the set up of IKEv2/IPsec SA 
> > at the MN 
> > > with the HA - for one, it could be that the need for 
> > sending a BU is 
> > > what does that, which would preclude setting up the SA 
> > while at home.
> > 
> > the mobile node as a regular IPv6 host can setup any number 
> > of IPsec SAs it wants. it is a matter of configuring the 
> > mobile node to setup an IPsec SA for protecting protocol 135, 
> > mh type 6 to the HA as soon as it boots up or as soon as it 
> > configures a home agent. you can do this for any protocol in 
> > your stack.
> > 
> 
> As for configuring the MN to set up an IKEv2 SA for protocol 
> 135 upon HA
> assignment, it makes a lot more sense to me that a MIP6 implementation
> should trigger the IKEv2 SA set up upon HA assignment, without a need
> for this being a configuration. 

why? it could just be a security policy which 
triggers this. 

> 
> > > > > Actually,
> > > > > there are a few things to mention here: 
> > > > > 
> > > > > 1. The MN may first obtain an IP address and then discover
> > > > it is home,
> > > > > after HA discovery/assignment.
> > > > >
> > > > > 2. If it wants to set up the IKEv2 SA, it must request the
> > > > configured
> > > > > IP address to be its home address.
> > > > >
> > > > > 3. If the HA assigned a different HoA for whatever reason,
> > > > the MN must
> > > > > use that and may release the address it configured earlier.
> > > > >
> > > > > 4. The IKEv2 SA in this case can be created with the HoA -
> > > > hence, the
> > > > > address on that SA may not change when the MN hands off.
> > > > > 
> > > > > It would be good to capture these in the document. 
> > > > 
> > > > this is standard behavior. in a typical IKEv2 
> implementation, the 
> > > > initiator can propose an address in the INTERNAL_IP6_ADDRESS 
> > > > attribute.
> > > > the responder can honor that or propose a new address. if 
> > there is a 
> > > > new address in the config reply, the initiator starts 
> > using the new 
> > > > address.
> > > > 
> > > 
> > > I understand standard IKEv2 behavior. This is about a recommended 
> > > behavior for the MN when it is home - an implementation may be 
> > > implemented such that it *never* proposes an address in the 
> > > INTERNAL_IP6_ADDRESS attribute - in this case, the MN 
> benefits from 
> > > requesting the configured address, due to the fact that it 
> > realized it 
> > > is home.
> > 
> > that would be an implementation limitation. any
> > IKEv2 implementation should be have this configurable on the 
> > initiator. the initiator can either a propose an address or 
> > request an address.
> > there is nothing to recommend. it is one of the things that 
> > should be left configurable.
> > 
> 
> This is not a blanket configuration. In this case, the MN 
> would request
> an IP address in the attribute when it is on the home link, but not
> while bootstrapping on a visited link, for instance. 

if you want to do this, just configure your MN 
to always request an IP address when it is on 
the home link but not while it is bootstrapping 
from a visited link. or the other way around.

Vijay

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Apr 2006 12:30:08 +0200

Vijay Devarapalli wrote:
> 
> 
>> -----Original Message----- From: Narayanan, Vidya
>> [mailto:[email-masked]] Sent: Thursday, April 13, 2006 12:14
>> PM To: Vijay Devarapalli; Giaretta Gerardo Cc: [email-masked] 
>> Vijay, The bootstrapping documents specify some MUSTs for MIP6
>> bootstrapping and also specify recommended behavior of DNS or IKEv2
>> as applicable for MIP6. If we go by the same argument that we can
>> "configure the MN to set up an SA as soon as it gets an HA
>> assigned", then, there are other parts of the document that should
>> receive similar treatment. For instance, going by your argument,
>> what value does the following statements in section 9.5 of
>> draft-ietf-mip6-bootstrapping-split add -
>> 
>> "A security association is required even if the DNS server is in
>> the same administrative domain as the Home Agent. The security
>> association SHOULD be separate from the security associations used
>> for other purposes, such as AAA."
>> 
>> One can claim that HA can be configured to say that the SA with the
>> DNS server is a separate one. But, the statement is there because 
>> we believe it is good recommended behavior and hence, should really
>> be part of the implementation and not a configuration.
> 
> in this case a MUST is required because it would be a bad idea for
> the HA to perform a DNS update without authenticating itself to the
> DNS server. otherwise any malicious node in the home network or a
> mobile node through the tunnel to its HA can send a DNS update on
> behalf of another mobile node. therefore the 'MUST' is required for
> securing the DNS update between the HA and the DNS server. it is not
> a configuration issue on the HA in this case.

Not only DNS update, but simple querying too should be secured.  It
would be bad for MN to be able to do a DNS querying without
authenticating it first, because in this way some rogue DNS server can
bootstrap the mobile into some rogue HA.

In which case, the DNS server and the mobile should authenticate to each
other first.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Apr 2006 09:29:40 -0700

Alex,

DNS has its own security mechanisms for security. See RFC 4033. Section 9.1 
in the bootstrapping draft discusses the security considerations for DNS in 
bootstrapping.

            jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, April 24, 2006 3:30 AM
Subject: Re: [Mip6] Bootstrapping on the home link

>>> PM To: Vijay Devarapalli; Giaretta Gerardo Cc: [email-masked] Subject: 
>>> RE: [Mip6] Bootstrapping on the home link
>>>
>>> DNS server is a separate one. But, the statement is there because we 
>>> believe it is good recommended behavior and hence, should really

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Apr 2006 18:36:43 +0200

James Kempf wrote:
> Alex,
> 
> DNS has its own security mechanisms for security.

Mechanisms and accepted limitations.

So do you agree that HA discovery based on DNS (be it SRV or simple
query) is not secure until MN queries the HA address in a secure manner?

Do you also agree that to a certain extent this DNS querying can happen
in a secure way (after IKE in visited domain), as well as in a
non-secure way (w/o IKE in the visited domain)?

> See RFC 4033. Section 9.1 in the bootstrapping draft discusses the 
> security considerations for DNS in bootstrapping.

I read it.  I'm left with the impression that DNS querying in the
visited domain can't be guaranteed secure because all DNS Servers aren't
known to be secure.

Knowing this, do you agree that the entire argument claiming DHAAD is 
not good because it is insecure applies to DNS HA discovery as well?

Alex

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Apr 2006 09:50:44 -0700

> query) is not secure until MN queries the HA address in a secure manner?

No. RFC 4033 describes the architecture of DNS security. It is up to 
operators to deploy that if they want secure DNS lookup. Section 9 of the 
bootstrapping draft has recommendations about this.

> non-secure way (w/o IKE in the visited domain)?

IKE isn't necessary. The operator needs to deploy DNSSEC.

> Knowing this, do you agree that the entire argument claiming DHAAD is not 
> good because it is insecure applies to DNS HA discovery as well?
>

No. If people don't deploy and use the protocols for securing DNS, then of 
course lookup won't be secure. IETF has no power or leverage to get people 
to deploy anything. And the MIP6 group can't go around recommending security 
solutions that are not standard (such as using IKE to secure DNS) just 
because people today don't deploy the recommended security measures for a 
protocol.

IMO, the bootstrapping draft adequately covers the issue of DNS security, 
and we have discussed this numerous times on the list in the past. I don't 
understand why you are raising this issue again. If you have some problem 
with the text in Section 9 that discusses the issue, then I would suggest 
you post some *specific changes in the text* and not these general arguments 
that we have already been over in the past. In order to make progress we 
need to move beyond rehashing the same issues again and nail down the text 
we want to submit to the IESG.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Apr 2006 19:09:18 +0200

James Kempf wrote:
> operators to deploy that if they want secure DNS lookup. Section 9 of 
> the bootstrapping draft has recommendations about this.

Ok.

Remark that DNS lookup may happen securely to DNS operators without 
DNSSEC (because operators have a SIM card in the phone) but at the same 
time insecurely for somebody discovering its HA via that apparently 
secure DNS (because same operators often use MAC address as the 
equivalent of the SIM card).  I.e. the DNS looks secure for the operator 
itself but a user may be attackable if uses a HA not provided by that 
operator (the split scenario).

> IKE isn't necessary. The operator needs to deploy DNSSEC.

Ok.  And if the operator deploys DNSSEC does the MN also need to use 
DNSSEC?  In order for the DNS-based bootstrapping procedure to work 
securely will the MN need to run DNSSEC?

> No. If people don't deploy and use the protocols for securing DNS, then 
> of course lookup won't be secure. IETF has no power or leverage to get 
> people to deploy anything. And the MIP6 group can't go around 
> recommending security solutions that are not standard (such as using IKE 
> to secure DNS) just because people today don't deploy the recommended 
> security measures for a protocol.
> 
> IMO, the bootstrapping draft adequately covers the issue of DNS 
> security, and we have discussed this numerous times on the list in the 
> past. I don't understand why you are raising this issue again.  If you
> have some problem with the text in Section 9 that discusses the issue, 
> then I would suggest you post some *specific changes in the text* and 

How about changing the draft title to "DNS-based Mobile Node 
Bootstrapping"?  This would leave the place for a "DHAAD-based Mobile 
Node Bootstrapping" draft.  There are no security or preconfig amount of 
information discriminators between the two.  I.e. one can't say that any 
one method is more secure or requires less pre-configuration.

> not these general arguments that we have already been over in the past. 
> In order to make progress we need to move beyond rehashing the same 
> issues again and nail down the text we want to submit to the IESG.

James, remember dhaad-harmful?  Remember WG mike discussions where DHAAD 
was discarded as insecure?  When somebody discards some protocol (DHAAD) 
on security grounds one would expect at least a more secure version of 
said protocol, not a fortunate assumption on how people should deploy 
yet other protocols (DNS).  When ND was acked as non-secure nobody went 
out proposing to discover the AR via DNS, instead they worked out SeND.

But I'll get back to the text section 9 on draft-bootstrap-split and 
comment on it.

Alex