Subject: RE: Solutions ...

From: Paal Engelstad <[email-masked]>
Date: Tue, 15 Jan 2002 10:52:30 +0100

It seems like most people take for granted that PAA should be located on the AR as default, while localizing it other places might be "useful". Have I missed out something?

In my mind, authentication (e.g. in order to authorize network access or not) and policy enforcement (e.g. discard packets of unauthenticated & unauthorized users) are separate matters. PAA is only concerned with the authentication part, while enforcement of network access, on the other hand, is handled by firewalls, security gateways, and other things that are outside the scope of PANA WG. Therefore, as long as PAA has a means to communicate with this equipment (e.g. a MIDCOM or a proprietary protocol), and can be reached by roaming nodes, PAA can be localized anywhere.

Furthermore, address assignment cannot be enforced by the AR in my opinion. In fact, a malicious node can use whatever IP address it would like - but some IP addresses would not be useful if there is for example a firewall installed on the AR or CR. If address assignment cannot be enforced anyway, why not assume that the roaming node always has aquired an IP address prior to authenticating?

I would appreciate if someone would clarify the points I may have missed out (even if it might have beed discussed before I subscribed to the list). Thanks.

Paal

> 
> Fra: Erik Nordmark <[email-masked]>
> Dato: 2002/01/14 Mon AM 10:01:56 CET
> Til: [email-masked]
> Tema: Solutions ...
> 
> Folks,
> 
> Given the work items in the charter it seems quite early to start discussing
> solutions.
> I'd much prefer if the WG woulf focus their energy on the scenarios and 
> requirements to make sure we can produce the minimum set of useful stuff.
> For instance, the model seems to be that the PAA can be either in the
> first-hop router or further into the network. It would be useful for
> us to understand the tradeoffs between those two approaches and
> determine whether both are indeed required. (The generality might be
> "useful" which is not the same as it being "required".)
> 
> Oh - and for those that can't stay away from thinking about solutions
> even though it is a bit too early: 
> As far as I understand the solutions that are being discussed
> they don't talk about a way to detect when the client has been disconnected,
> dealing with multiple access routers on the link, etc.
> (Of course, I could be wrong.) 
> 
>    Erik
> 
>

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 Jan 2002 20:22:39 +0100 (CET)

> In my mind, authentication (e.g. in order to authorize network access or
> not) and policy enforcement (e.g. discard packets of unauthenticated &
> unauthorized users) are separate matters. PAA is only concerned with the
> authentication part, while enforcement of network access, on the other hand,
> is handled by firewalls, security gateways, and other things that are
> outside the scope of PANA WG. Therefore, as long as PAA has a means to
> communicate with this equipment (e.g. a MIDCOM or a proprietary protocol),
> and can be reached by roaming nodes, PAA can be localized anywhere.

I suspect there are scalability issues with having single PAA serving a very
large number of devices. For large networks there might also be
issues in the PAA always knowing the topology so that it can determine from
the device' IP address where in the network it is attached (so that it knows
what enforcement points it need to update once a device is authenticated).

> Furthermore, address assignment cannot be enforced by the AR in my opinion.
> In fact, a malicious node can use whatever IP address it would like - but
> some IP addresses would not be useful if there is for example a firewall
> installed on the AR or CR. If address assignment cannot be enforced anyway,
> why not assume that the roaming node always has aquired an IP address prior
> to authenticating?

If the temporary addresses in RFC 3041 are viewed as required one could make
a much stronger statement in the IPv6 space; that PANA must allow
hosts to use RFC 3041 without the provider being able to prevent their use.

   Erik