Subject: [Mip6] review of draft-ietf-mip6-bootstrap-ps-03.txt

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Sep 2005 16:56:47 +0300

Hi,

I have read the latest version of this draft. Some comments
below.

Overall: This is a well written document, ready to
be published. It covers the issues well. Some nits
and a few technical issues are noted below, however.

Technical:

>    o  A basic assumption in the Mobile IPv6 RFC [RFC3775] is that there
>       is a trust relationship between the mobile node and MSP.  This
>       trust relationship can be direct, or indirect through, for
>       instance, an ASP that has a contract with the MSP.  This trust
>       relationship can be used to bootstrap the MN.

Actually, in RFC 3775 there's an assumption about a relationship
between the mobile node and its home agent. The concept of an
MSP is rather defined in the reviewed document. I understand
that the concepts are very close, but the distinction may be
important, because it implies the difference between operating
directly with a home agent vs. through supporting infrastructure
such as AAA. Suggest s/and MSP/and its home agent(s)/.

Same issue also 9.1.

>    o  Yet another assumption is that some identifier, such as NAI, as
>       defined in [I-D.ietf-mip6-mn-ident-option-02] or [RFC2794] is
>       provisioned on the MN which permits the MN to identify itself to
>       the ASP and ASP.

This assumption that may not have to be true if
you consider all possible solutions - though its certainly
true in the solutions that are being designed right now.
(A bare bones bootstrapping scheme would allocate a
local home agent via DHCP and generate a limited-lifetime
SA using leap-of-faith. This would need to be supported
with a return routability check on every home registration.)

Also, s/ASP and ASP/ASP and MSP/ ?

> 6.  Network Access and Mobility services

This is a good section, but it appears to make
the assumption that current access
network and bootstrapping go together. I think
we should retain a degree of independence between
the mobility and access service, even if we use
it for bootstrapping. One aspect of this independence
is the ability to get the mobility service from somewhere
and keep on using it afterwards. For instance, you
probably want to visit your private home network
once in a while, and that network runs typically on
a bare DSL service that isn't likely to offer a lot
of service, let alone mobility on top of it.

> 3.  Design Goals

I liked the goals.

> 4.  Non-Goals

I was involved in the work of the design team in its
early phases, and probably agreed with these at the time.
However, I've recently started to wonder whether a
zero-config model (i.e. no trust relationship at all)
would actually be something that we should do as well.
Technically, this is possible. Provider input points to the
direction of always having a trust relationship, but I have a
feeling that we are developing a lot of complicated
technology, and the zero-config model would actually
allow us to reduce complexity instead, perhaps leading
to wider deployement.

Editorial

>       The serving network accesss provider may or may not additionally

s/accesss/access/

>       legitimate home agent address or boostrapping for the IPsec SAs

s/boostrapping/bootstrapping/

>    dependent.  For instance, the MN may bootstrap everytime it boots,

s/everytime/every time/

>    relevent IPsec RFCs must be quite strong.  Provisioning of keys and

s/relevent/relevant/

Maybe also "... we have to place a lot of trust to these security 
associations:
Provisioning of keys ..."

--Jari

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

---

From: "James Kempf" <[email-masked]>
Date: Fri, 16 Sep 2005 09:19:11 -0700

Jari,

> allow us to reduce complexity instead, perhaps leading

Speaking with my service provider hat on, I don't think it is really a hard 
and fast service provider requirement for this. Rather, there is a basic 
assumption in RFC 3775 that this relationship exists. There is no provision 
for return routability checks on the home agent, for example. If the working 
group is interested in updating RFC 3775 to remove this restriction, then I 
think bootstrapping with no predefined trust relationship would be possible. 
However, some active WG members with whom I've spoken privately (and who are 
not associated with service providers) are opposed to RR with the home 
agent, so it may not be so easy to get concensus on this. Personally, I 
think that the lack of return routability with the HA is a problem 
regardless of whether the user has a preexisting trust relationship with a 
service provider or not. Perhaps I'm missing something, but I fail to see 
how a service provider can spot a redirection attack from a fully authorized 
user through the home agent, unless the victim calls up (presumably from 
another device than the one under attack) and complains.

In addition, if you look at the details of how the bootstrapping is done, 
there is nothing in the protocol to prevent, say, a WLAN ISP from having a 
list of MIP6 MSPs on its login page, which the user can then click on and 
obtain the SRV RRs for home agents from one of the MSPs. There is an issue 
of how the MSP authenticates the user through IKE, but if the MSP pushes a 
Web page to the mobile node (or perhaps the Web page is pushed via the WLAN 
ISP's login), the user could set up the account to use EAP, or get a 
certificate from the MSP to identify itself, or the mobile node could even 
provide a self-signed certificate, as you mention. The MSP could then use 
the same kind of accountless, credit card charging that is used widely by 
WLAN hotspot ISPs in the US.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Sep 2005 20:57:14 +0300

James Kempf wrote:

> Speaking with my service provider hat on, I don't think it is really a 
> hard and fast service provider requirement for this. Rather, there is 
> a basic assumption in RFC 3775 that this relationship exists. There is 
> no provision for

Ok.

> return routability checks on the home agent, for example. If the 
> working group is interested in updating RFC 3775 to remove this 
> restriction, then I think bootstrapping with no predefined trust 
> relationship would be possible. However, some active WG members with 
> whom I've spoken privately (and who are not associated with service 
> providers) are opposed to RR with the home agent, so it may not be so 
> easy to get concensus on this. 

Ack.

(Note: this would not be an RR that everyone would have to run,
just an RR that those zero-config clients need to run. But I'm not
really trying to sell my solution. Just making an observation
wrt to the document at hand.)

> Personally, I think that the lack of return routability with the HA is 
> a problem regardless of whether the user has a preexisting trust 
> relationship with a service provider or not. Perhaps I'm missing 
> something, but I fail to see how a service provider can spot a 
> redirection attack from a fully authorized user through the home 
> agent, unless the victim calls up (presumably from another device than 
> the one under attack) and complains.

That is the process - and it would be the same process if the hosts were
attached directly to the providers network, where there's be no
Mobile IPv6.

> In addition, if you look at the details of how the bootstrapping is 
> done, there is nothing in the protocol to prevent, say, a WLAN ISP 
> from having a list of MIP6 MSPs on its login page, which the user can 
> then click on and obtain the SRV RRs for home agents from one of the 
> MSPs. There is an issue of how the MSP authenticates the user through 
> IKE, but if the MSP pushes a Web page to the mobile node (or perhaps 
> the Web page is pushed via the WLAN ISP's login), the user could set 
> up the account to use EAP, or get a certificate from the MSP to 
> identify itself, or the mobile node could even provide a self-signed 
> certificate, as you mention. The MSP could then use the same kind of 
> accountless, credit card charging that is used widely by WLAN hotspot 
> ISPs in the US.

Yes. Though I'm not sure I want more credit card login pages.

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 16 Sep 2005 22:53:48 -0700

> allow us to reduce complexity instead, perhaps leading

I agree with the general idea of not assuming that there must be some 
pre-existing trust (at least not one embodied in the protocol).

For instance, in many enterprise environments the trust to get network 
access is based on having physical access to the buildings. Then one can 
plug in to the Ethernet jacks in conference rooms etc and DHCP will hand 
out addresses.
Can we make getting Mobile IP service within that (enterprise) network 
as easy? Give me an address with DHCP and then allow me to use that as a 
HA as I move around? Perhaps this just falls out from having HAs that 
accept self-signed certs and straight RFC 3775?

But I think it would make sense to have the goals include this type of 
cases.

    Erik

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Sep 2005 10:14:17 +0200

In your previous mail you wrote:

   > However, some active WG members with 
   
=> IMHO your prediction about no consensus about this is right (:-).

=> perhaps the rr-cookie mechanism should be extended to the MN-HA case?
The mechanism itself has nothing which limits it to the MN-CN case,
and the fact it is controlled by the MN peer (here the HA) should be
an advantage.
BTW the I-D name is draft-dupont-mipv6-rrcookie-01.txt (and .xml).

Thanks

[email-masked]

PS: my I-D "DHAAD considered harmful" is ready (the idea is to replace the
current DHAAD mechanism by the SRV DNS RR one).