Subject: [Autoconf] Re: Autoconf Digest, Vol 23, Issue 18

From: "Hasnaa Moustafa" <[email-masked]>
Date: Fri, 7 Dec 2007 20:11:05 +0100

Hi Teco,

Thanks for raising this interesting issue.

Considering Commercial ISPs is the way for wide scale MANET deployments. I
believe that IP autoconfiguration is one of the tough issues blocking the
real MANET deployment by ISPs.

Even if we think of L2 security (existing in WLAN hotspots deployed by
ISPs), it is not feasible to apply it in a MANET multi-hop environment, and
no standard solution existing now providing L2 security in multi-hop MANET
environment.

I agree with your point that ISP should provide IP autoconfiguration for
their clients or even other legitimate clients (belonging to other ISPs, for
instance, if there is a trust relationship between different ISPs). And
there is a number of requirements that can exist in this case.
But the main question (before talking about this issue) concerns the
autoconf WG scope: is the WG looking for IP autoconf solutions
concerning such type of scenario --> (MANETs that extends the service
coverage of an ISP access network? And of coarse: this is a connected
MANET.)

IMHO, this is an important scenario highlighting a concrete MANET
application and having special requirements.

Hassnaa
----------------------------------------------------------------------------------------------------
Date: Thu, 6 Dec 2007 21:02:39 +0100
From: "Teco Boot" <[email-masked]>
Subject: [Autoconf] Supporting commercial ISPs
To: <[email-masked]>
Message-ID: <013a01c83843$07d54200$177fc600$@nl>
Content-Type: text/plain;       charset="us-ascii"

I have a somewhat fundamental question on AUTOCONF requirements; do we
consider commercial ISPs?

I think in real world, we have two environments: private networks and
Internet.

Private networks could use L2 security and within the network there is no
hard requirement for access control. However, even in these private networks
access control is getting important.

For Internet, ISP provide access to their customers. And probably to their
customers only. I wonder how we can support this kind of operation.

I appreciate any comment from ISPs, on what they want to be supported. I
think the outcome has a large impact on the requirements.

Teco.

------------------------------

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

End of Autoconf Digest, Vol 23, Issue 18
****************************************
_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 10 Dec 2007 15:37:56 +0100

Hi Hasnaa,

Thanks for the clear response.
I think we should include some scenarios on extending service coverage area
of an ISP access network in the PS document. Suggested scenarios:

1)
Full trust between Access Routers and MANET Routers. MANET Links and Access
Links are protected using L2 security. Border Routers and Access Routers can
be integrated, i.e. Access Routers may run MANET routing protocol. Access
Routers may provide prefixes and addresses.
The question here is, what is the added value of Autoconf? IMHO all nodes
are provisioned before deployment; e.g. security parameters and key
material. Configuring addresses is not that much extra.

2)
No trust between Access Routers and MANET routers. Border routers use
protected L2 links to Access Routers. Border Routers are fixed or mobile.
Access Routers do typically not provide prefixes, they only provide
addresses to attached nodes.
In this case, assistance from NEMO functionally and HA could be used for
providing prefixes to Border Routers. MANET routing protocol may run on MRHA
tunnel.
The question here is, what is the trust relation between the MANET Routers?
And also what is the added value of Autoconf in case of configured security
parameters and key material?

3)
New security mechanism for setting up trust relation between Access Routers
and MANET Routers. In this case, each MANET Router sets up a secured link to
one or more Access Routers. I think network operators require some kind of
hardware authentication (e.g. SIM), or maybe some form of certificates could
be used. NEMO can be used in this case also.

I did not use "new terminology" Internet Configuration Provider, as I do not
know what this is.
I used Access Router instead of ISP Edge Router, as this is a well known
name for this entity (RFC3753). 

What do you think?
Any comment from others, familiar with ISP / network operator requirements?

Teco.

----------------------------------------------------------------------------
------------------------
Van: Hasnaa Moustafa [mailto:[email-masked]] 
Verzonden: vrijdag 7 december 2007 20:11
Aan: [email-masked]
CC: [email-masked]
Onderwerp: Re: Autoconf Digest, Vol 23, Issue 18

Hi Teco,

 

 
Hassnaa
----------------------------------------------------------------------------
------------------------
To: < [email-masked]>

Teco.

---

From: "Hasnaa Moustafa" <[email-masked]>
Date: Tue, 11 Dec 2007 16:37:35 +0100

Hi Teco,

Thanks for you reply.

There are a number of points that are not so clear for me.

Please see below.

Hassnaa

On 12/10/07, Teco Boot <[email-masked]> wrote:
> I think we should include some scenarios on extending service coverage
> area of an ISP access network in the PS document. Suggested scenarios:
>

Hassnaa: I am not so sure if we need a special scenario for this, as this
type of scenario is a connected one. Then the description of the connected
scenario in the PS could include such a case (MANET connected to an ISP
access network).

> Routers may provide prefixes and addresses.

Hassnaa:
How do you differentiate between MANET links and Access links?
-If Access Routers and Border Routers are integrated in one entity (as you
mentioned), then there is no difference, IMO, between Access links and MANET
links.
- When talking about L2 Security (for instance 802.1x model), I could not
see how it could take place in a multi-hop MANET environment. So far,
the existing standard mechanisms function in a WLAN environment (protecting
the link between a mobile node and an Access point). So saying MANET links
are protected using L2 security --> implies the existence of a mechanism
that assures L2 security within the multi-hop environment (which does not
conform with the reality).

> material. Configuring addresses is not that much extra.

Hassnaa:
I did not get, what do you mean by "added value of Autoconf" --> for me the
added value of autoconf is the "IP address provision for manet routers"
(Maybe I miss something!).

2)
> addresses to attached nodes.

Hassnaa:
If there is no trust between the Access Routers and the MANET routers, then
this does not conform with a MANET connected to an ISP access network. For
commercial deployment of MANETs, each manet router is considered as a
"mobile client", and this "mobile client" could not be connected to the ISP
access network if he is not legitimate (implying "trust relationship" with
the Access Routers directly or indirectly. Directly, if the mobile client is
a subscriber with the ISP that owns the Access routers, while indirectly if
the mobile client is a subscriber with another ISP that has a trust
relationship with the current ISP.

> parameters and key material?

Hassnaa: Same previous comment for the "added value of Autoconf"!

3)
> be used. NEMO can be used in this case also.

Hassnaa: I think that this point goes into details concerning the security
issue (which is not sure to be in the scope of the WG).

> name for this entity (RFC3753).

Hassnaa: IMHO, it is interesting to include the case of "a MANET
connectected to an ISP access network" in the "Connected MANET subsection in
the PS" --> I could eventually provide some text if there is an agreement on
this point.
If there is also an agreement on including a requirement section in the PS
document "the point that was discussed in Vancouver, but not yet concluded"
--> it would be then important to consider some requirements related to this
case (this would be security requirements, as well as operational
requirements).

Comments and feedbacks are more than welcome.

> Even if we think ofL2 security (existing in WLAN hotspots deployed by
> ISPs),it is not feasible to apply it in a MANET multi-hop environment, and
> no standard solution existing nowproviding L2 security in multi-hop MANET
> environment.
>
> But the mainquestion (before talking about this issue) concerns the
> autoconf WG scope: is the WG looking forIP autoconf solutions
> concerningsuch type of scenario --> (MANETs that extends the service
> coverage of an ISPaccess network? And of coarse: this is a connected
> MANET.)
>

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 12 Dec 2007 09:53:21 +0100

Hi Hassnaa,

Comments inline.

Van: Hasnaa Moustafa [mailto:[email-masked]] 
Verzonden: dinsdag 11 december 2007 16:38
Aan: [email-masked]
CC: [email-masked]
Onderwerp: Re: [Autoconf] Supporting commercial ISPs

Hi Teco,

Thanks for you reply.

Please see below.

Hassnaa

Hi Hasnaa,

 

1)

Hassnaa:

[Teco:] 

In this case, there is no access link.

- When talking about L2 Security (for instance 802.1x model), I could not
see how it could take place in a multi-hop MANET environment. So far, the
existing standard mechanisms function in a WLAN environment (protecting the
link between a mobile node and an Access point). So saying MANET links are
protected using L2 security --> implies the existence of a mechanism that
assures L2 security within the multi-hop environment (which does not conform
with the reality).

[Teco:] 

I am not sure 802.1x cannot be used for MANET links. 802.11i-2004 describes
how this should work for IBSS.

I prefer using pre-shared keys in MANET.

Many existing MANET products use local configured settings, for security and
other. Manual provisioning of MANET Local Addresses is natural in such
cases. This is why I asked what the added value of Autoconf is.

Hassnaa:

[Teco:] 

Yes, but when keys (and other settings) need to be configured before
deployment, why not configuring MLA also?

For global addresses, Autoconf functionality can be useful.

2)

Hassnaa: 

[Teco:] 

In both the  "directly" and "indirectly" case, each MANET Router that can
access the ISP network is also Border Router, OK?

tunnel.

[Teco:]

I am just asking myself this question on added value of Autoconf.

If access to ISP network is managed on Access Router - Border Router link,
current global address assignment protocols are used and Autoconf is not
needed.

If there is no preconfigured trust relation between the MANET Routers, but
MANET Routers want to communicate with each other, MLA is needed. Here
Autoconf functionality can be useful.

3)

[Teco:] 

Partly agreed. I think we should not work on security solutions, but I think
it is important to know what the requirements for real world deployment are.
If we do not cope with it, the newly defined protocols are dead already. I
think it is better to circumvent this.

One of the ideas in Autoconf is, is providing a facility for multihop MANET
communication between a MANET Router and the Internet. Our goal is to
provide a Problem Statement document. If there is a security problem with
this topology, I do not see a reason why we should not describe this.
Solving the problem is another thing, it requires rechartering Autoconf or
something else.

What do you think?

[Teco:] 

This would be great!

Teco.

 

 

Teco.

------------------------
Van: Hasnaa Moustafa [mailto:[email-masked]]
Verzonden: vrijdag 7 december 2007 20:11
Aan: [email-masked]  <mailto:[email-masked]> 
CC: [email-masked]
Onderwerp: Re: Autoconf Digest, Vol 23, Issue 18

Hi Teco,

Hassnaa
----------------------------------------------------------------------------
------------------------
Date: Thu, 6 Dec 2007 21:02:39 +0100
From: "Teco Boot" < [email-masked]>
Subject: [Autoconf] Supporting commercial ISPs
To: < [email-masked]>
Message-ID: <013a01c83843$07d54200$177fc600$@nl >
Content-Type: text/plain; charset="us-ascii"

Teco.