Subject: RE: [Mip6] Conclusion of the consensus call relatedtothebootstrapping I-Ds

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 22 Aug 2006 13:41:27 -0400

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Tuesday, August 22, 2006 11:43 AM
> To: Alper Yegin; 'Basavaraj Patil'; [email-masked]
> Subject: Re: [Mip6] Conclusion of the consensus call
> relatedtothebootstrapping I-Ds
> 
> Alper,
> 
> >From an interoperation standpoint, if draft-jang is Proposed
Standard, is
> there really any need for the integrated scenerio document to be
Proposed
> Standard as well? As I recall, there are a number of assumptions about
> system architecture in the document that may be specific to certain
SDO
> architectures. Would it make more sense to expand the document's scope
> into
> a survey of how DHCP is used for bootstrapping in various SDO
> architectures
> and make it Informational?
> 
[KC>] The problem statements for mip6 bootstrapping talks about two
scenarios split and integrated. We have two I-Ds for each scenario. Now,
you are questioning the need for a solution document for the integrated
scenario to be standards track document or not. What about split
scenario document? The split scenario document is nothing but a
framework with a handful of (rather useless) things like DNS update and
HL prefix etc. Integrated scenario is likely to be widely deployed,
where as the split scenario doesn't even have any buyer. 

So, if you want to go down this path, we will end up making both the
documents informational. If not both of them should remain standards
track.

>                        jak
> 
> ----- Original Message -----
> From: "Alper Yegin" <[email-masked]>
> To: "'Basavaraj Patil'" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, August 22, 2006 5:00 AM
> Subject: RE: [Mip6] Conclusion of the consensus call related
> tothebootstrapping I-Ds
> 
> 
> >
> > Hi Raj,
> >
> > Given that the options were:
> >
> > 1. Have a single document which specifies the solution describing
> >   bootstrapping with DHCPv6 which includes the DHCPv6 options that
> >   are needed.
> >
> > 2. Specify the DHCP options needed for bootstrapping with DHCPv6 in
a
> >   separate document and have this referenced in the solution I-D.
> >
> >
> > And the WG consensus was for option 2, we cannot be still asking:
> >
> >> Is the integrated scenario bootstrap document still useful or
needed?
> >
> > This question is already answered. That was the whole idea behind
this
> > consensus call (one vs. two documents).
> >
> > Alper
> >
> >
> >
> > _______________________________________________
> > Mip6 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mip6
> >
> 
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 22 Aug 2006 11:28:46 -0700

Kuntal,

jak>> Let's try to avoid emotional language, shall we? We're trying to 
determine what would be the best role for this document, in terms of its 
potential customers.

jak>> I think you mean draft-jang will be widely deployed. As I recall 
someone posted email a while back saying that there was no plan by any other 
SDO to adopt the integrated draft as is, just the two draft-jang DHCP 
enhancements.

jak>> We're not discussing the split draft here. If you want to propose 
changing it, then start a separate thread.

jak>> The integrated draft has some protocol enhancements, in Sections 3.5.1 
and 3.5.2. These could be separated out into a separate, PS draft, just as 
the WG has decided to do with draft-jang, and the system description in the 
rest of the draft could be published as Informational, with perhaps some 
additional work to complete the survey of what other SDOs are doing. That 
way, the other SDOs could pick and choose what part of the DHCP solution 
they want to standardize and how to combine them, and the integrated draft 
could serve as a documentation of how other SDOs are using DHCP 
bootstrapping in their system architecture. This seems to be more consistent 
with the way most WG members seem to want the DHCP solution to be 
standardized.

            jak

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 22 Aug 2006 14:13:48 -0500

Having spent a few months on deliberating how DHCP options required for
bootstrapping be specified, lets not go back in time and start discussing if
the intergrated scenarios I-D is necessary or not.

When the design team was formed, the conclusion after the completion of the
split scenarios I-D was that a solution for the integrated scenario is
needed as well and hence the creation of the WG I-D.

I have also been told by 3GPP2 (liaison) that they have a dependency on the
integrated scenarios I-D.

Hence I would recommend that we stop this discussion and lets work on
completing the bootstrap solutions work.

-Raj

---

From: "James Kempf" <[email-masked]>
Date: Tue, 22 Aug 2006 12:41:11 -0700

Raj,

I'm not questioning the need for the document. What I'm asking is whether 
the document, as it stands, is consistent with the direction the WG wants to 
go in, given the consensus decision not to include the DHCP options into it. 
It seems to me that the direction is for the various pieces of the 
intergrated solution as separate documents.

Regarding the 3GPP dependency, do they really want the system description 
part or are they really interested in the relay to server options?

            jak

----- Original Message ----- 
From: "Basavaraj Patil" <[email-masked]>
To: "ext James Kempf" <[email-masked]>; "Chowdhury, Kuntal" 
<[email-masked]>; "Alper Yegin" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, August 22, 2006 12:13 PM
Subject: Re: [Mip6] Conclusion of the consensus call related to the 
bootstrapping I-Ds

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 22 Aug 2006 16:13:11 -0500

Hi James,

Stepping back from the specifics of the documents that we have today in the
WG w.r.t bootstrapping, I believe what the WG is chartered (which needs to
be updated BTW), is to develop a solution or solutions for bootstrapping
MIP6. I think we disccovered fairly early on that one bootstrapping solution
does not fit all environments. We are now even considering adopting Vijay's
draft which specifies bootstrapping in the case of the use of the
authenication protocol. But that's not the point here.

The WG direction is to develop a set of bootstrapping solutions that can be
used in various deployment scenarios. The scenarios that we have specified
in the WG today are based on the use of IKE for bootstrapping for the cases
that we call split and integrated. The issue about whether the DHCP options
should be specified within the integrated scenarios document or separately
is simply a matter of how we split the documents.
Consensus was that keeping the DHCP options is preferred because of various
reasons (as has been discussed at length).

My recommendation is that we move forward with the set of existing I-Ds
which include the problem statement, Split scenario, Integrated scenario,
and DHCPv6 options.

W.r.t what 3GPP2 really wants from the integrated scenarios I-D, I believe
they require the IKE based bootstrapping solution for MIP6 and not just the
DHCP options.

-Raj

---

From: "James Kempf" <[email-masked]>
Date: Tue, 22 Aug 2006 14:25:57 -0700

Raj,

> which include the problem statement, Split scenario, Integrated scenario,

As you know, I was not in favor of splitting off the DHCPv6 options into 
separate documents. However, since it seems like that is what the WG wants, 
I was just trying to get an idea of whether that should apply to the relay 
to server options too. As I mentioned to Kuntal, I think this would make a 
certain amount of sense from an organizational standpoint (protocol mods in 
separate, small PS documents, system architecture in larger Informational 
document) which is what I thought Alper was trying to achieve. I frankly 
don't care much either way.

Does anybody else in the WG have an opinion on this?

> they require the IKE based bootstrapping solution for MIP6 and not just 

Then they will need to refer to something more than the integrated document. 
The IKEv2 bootstrapping is specified in the split document, not the 
integrated document.

Maybe we need the 3GPP2 liason to step forward and say what 3GPP2 wants, or 
is the liason you?

            jak

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 23 Aug 2006 01:12:39 -0700

I have asked the 3gpp2 liaison to respond. In the meantime, here is my
take on this whole thread of emails:

Pending confirmation from the liaison, I believe that 3gpp2 plans to use
DHCP as the means of discovering the HA. Further, the plan is to use
IKEv2 to obtain a HoA. 

I don't really have an opinion on what track each of these documents get
published under or whether they are separate or not. I stated a
preference during the consensus call and that's that. 

In my personal opinion, DHCP, as envisioned as being used to discover
HAs, is rather specific to certain scenarios and is not generically
applicable. The DNS-based solution is the more generic model that is
universally applicable. And, FWIW, I don't quite buy the security
problem with the DNS approach. If a provider is hosting a service such
as Mobile IP, the servers (i.e., home agents) must be globally reachable
or there is no service at that point. Even with the DHCP-based
mechanism, any attacker will happily learn the HA IP address in BUs and
BAs that are exchanged even if the argument is that the HA IP address is
given out in DHCP only to authenticated clients. Paranoid network
deployments better use DNSSEC to hand out addresses, preprovision IPsec
keys between the MN and HA, encrypt the BU/BAs using the preprovisioned
keys and subsequently use tunnel mode IPsec with a gateway to which they
are comfortable providing global reachability for data packets! 

It's at the end of a long day, but I think if you did all of the above,
it may be difficult for an attacker to learn the HA IP address :) 

My 2 cents,
Vidya

> Sent: Tuesday, August 22, 2006 2:26 PM
> To: Basavaraj Patil; Chowdhury, Kuntal; Alper Yegin; [email-masked]
> Subject: Re: [Mip6] Conclusion of the consensus call related 
> to thebootstrapping I-Ds
> 
> Raj,
> 
> > Stepping back from the specifics of the documents that we 
> have today 
> > in the WG w.r.t bootstrapping, I believe what the WG is chartered 
> > (which needs to be updated BTW), is to develop a solution 
> or solutions 
> > for bootstrapping MIP6. I think we disccovered fairly early on that 
> > one bootstrapping solution does not fit all environments. 
> We are now 
> > even considering adopting Vijay's draft which specifies 
> bootstrapping 
> > in the case of the use of the authenication protocol. But 
> that's not 
> > the point here.
> >
> > The WG direction is to develop a set of bootstrapping 
> solutions that 
> > can be used in various deployment scenarios. The scenarios that we 
> > have specified in the WG today are based on the use of IKE for 
> > bootstrapping for the cases that we call split and integrated. The 
> > issue about whether the DHCP options should be specified within the 
> > integrated scenarios document or separately is simply a 
> matter of how 
> > we split the documents.
> > Consensus was that keeping the DHCP options is preferred because of 
> > various reasons (as has been discussed at length).
> >
> > My recommendation is that we move forward with the set of existing 
> > I-Ds which include the problem statement, Split scenario, 
> Integrated 
> > scenario, and DHCPv6 options.
> >
> 
> As you know, I was not in favor of splitting off the DHCPv6 
> options into separate documents. However, since it seems like 
> that is what the WG wants, I was just trying to get an idea 
> of whether that should apply to the relay to server options 
> too. As I mentioned to Kuntal, I think this would make a 
> certain amount of sense from an organizational standpoint 
> (protocol mods in separate, small PS documents, system 
> architecture in larger Informational
> document) which is what I thought Alper was trying to 
> achieve. I frankly don't care much either way.
> 
> > W.r.t what 3GPP2 really wants from the integrated scenarios I-D, I 
> > believe they require the IKE based bootstrapping solution 
> for MIP6 and 
> > not just the DHCP options.
> >
>

---

From: "Tsirtsis, George" <[email-masked]>
Date: Wed, 23 Aug 2006 04:23:01 -0700

I agree that the security problems with DNS are not relevant but for
slightly different reasons. HAs are globally reachable entities. The
DHCP approach provides some obscurity by the fact that the system can be
made to work so that the DHCP server only talks to authenticated (i.e.,
known) entities. Obscurity, however, is not security. If attacking HAs
is a good attack the IP addresses of such HAs will be on the "hacker's
weekly" web site in no time.

In the Internet, major infrastructure equipment are always going to be
somewhat vulnerable, which is why we do generally avoid them and instead
we distribute functions. Until routing can deal with mobility, however,
we will have to have HAs, oh well :-)

George

> From: Narayanan, Vidya [mailto:[email-masked]]
> Sent: Wednesday, August 23, 2006 4:13 AM
> To: James Kempf; Basavaraj Patil; Chowdhury, Kuntal; Alper Yegin;
> [email-masked]

---

From: "Jean-Michel Combes" <[email-masked]>
Date: Wed, 23 Aug 2006 15:28:08 +0200

Hi,

At first, I have the strange feeling that this thread is going out of
scope from the initial subject :s
There is an old thread where security regarding HA
discovery/assignment was debated: "New charter item: HA assignment"
(http://www1.ietf.org/mail-archive/web/mip6/current/msg04859.html).

2006/8/23, Tsirtsis, George <[email-masked]>:
> slightly different reasons. HAs are globally reachable entities.

Don't agree. Depends who wants to reach it.

> The
> known) entities. Obscurity, however, is not security.

Agree :)

> If attacking HAs

HA are the point of fealure for IPv6 mobility protocols (MIPv6 and
furthermore NEMO). Trying to give the minimum of information can limit
the attacks.

> > as Mobile IP, the servers (i.e., home agents) must be globally

Don't agree: cf. the thread I mentionned before.

> > deployments better use DNSSEC to hand out addresses

In theory, DNSSEC may be used. Not in practical.

>> , preprovision
> IPsec
> > keys
>> and subsequently use tunnel mode IPsec with a gateway to which
> they

The goal is not that an attacker may be able to learn one HA IP
address but that an attacker learns _all_ the HAs IP addresses from
one MSP.

Best regards.

JMC.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 25 Aug 2006 13:55:36 +0300

For what its worth, I would like to see a document that explains
how the different protocol pieces are used together. Without
such a document, its hard to understand how the protocol
parts make sense and if they indeed work, are secure, etc.

The contents of that document is up to the group to decide
of course -- but it would be useful if matched with reality in
some currently planned deployments, likely 3GPP2. Make
sure there is sufficient joint participation, reviews, etc. with
them.

I can see that some further decisions may be needed on
e.g. what if any protocol parts remain in the integrated
document. I would suggest that to avoid wasting additional
time for purely editorial discussions, the WG focuses on
the technical content (what do we want?) and we let
the chairs decide how the content is packaged into
the documents, under the guidance of the consensus call
that we just concluded.

--Jari