Subject: Re: Re: List of Open Issues III

From: Paal Engelstad <[email-masked]>
Date: Fri, 15 Feb 2002 0:31:15 +0100

> Alper E. YEGIN writes:
> > > 1 - Authorization (Open)
> [...]
> > Why is this an open issue?
> 
> For one thing, it seems to be the case that there are situations where
> it's not possible to communicate via IP until the authorization has
> been done, and that authorization can't be done until authentication
> has completed.  

James,

I agree that PANA seems a little tricky in those cases. 

Personally, I would prefer a simple PANA protocol that works in most cases to a very complex solution designed to work in all different scenarios. We can always find situations where the PANA protocol will not work.

You say: "there are situations". It is not clear in my mind how "probable" these situations are. Is it your opinion that it is the general case, and by not allowing for more that binary authorization we will end up with a narrow niche product?

I am trying to clarify the tradeoff between the "market potential" for PANA and its complexity.

Thanks,
Paal
 
> The example case I gave was an 802.11 network that
> provided access to multiple ISPs based on VLANs behind the access
> point.  In order to make that work, there needs to be a way for the
> access point to determine the 'right' context for a given end node.
> 
> This problem is roughly analogous to the problems faced with 'equal
> access' requirements on shared networks.  (But uses trendy terms like
> "wireless" and "VLAN.")
> 
> The solution to that involves sending some sort of identifier from the
> end node to the access point to select the desired network.  The only
> question left is whether any authentication is involved.  If it's not
> involved, then the administrator has no control over which nodes may
> access which VLANs.  If it is involved, then there needs to be a way
> to establish credentials for the end node.  This is then complicated
> by the fact that the end node can't determine whose IP subnetwork (and
> therefore which address) will be used for authentication.
> 
> One PANA-based solution might be to allow the end node to pick an
> arbitrary address, and put a proxy PAA in the L2 access node.  This is
> sort of equivalent to the way compulsory L2TP tunnels are usually
> implemented: the access node looks at enough authentication
> information to make a determination of where to send the tunnel.  It
> can get pretty ugly.  Especially so since the end node will have to
> renumber after getting connected, and there's no obvious way that the
> end node will know that this is even needed.  That is to say: one of
> the suggestions originally put forward (not by me ;-}) was to use a
> temporary address to do the PANA authentication in order to open the
> IP floodgates for other protocols, including IP address assignment.
> But how is the end-node supposed to know that the IP address that it
> has isn't permanently valid?  And if there's a magic "please do
> something to get a new IPv4 address for yourself" message from the PAA
> to the PaC, how is this protected against attack?
> 
> Another case where the problem occurs is with systems -- in common use
> by ISPs -- that grant IP addresses in different ways based on the
> outcome of authentication.  Some end nodes may get fixed IP addresses.
> Some may get dynamic assignments.  To use PANA here means that you
> have to duplicate the BOOTP/DHCP trick of using a zero source address
> and rely on the access node to hot-wire an appropriate ARP entry and
> fill in the source address if it needs to do relaying.  Again, this
> can easily run into address-assignment problems in the IPv4 case.
> (That is, there are cases where the L2 relay needs to be able to
> assign an IPv4 address, but cannot until it authenticates the request
> in some way.)
> 
> > > 5 - Device Identifier and Multicast Addresses. (Open)
> [...]
> > > Given that the DI can an IP address, this means that
> > > in the multicast case you cannot use DI as an
> > > identifier (since several clients would be associated
> > > with a DI), or we need to change the above definition
> > > a little.
> 
> If it's an IP address, isn't it basically a *source* IP address?
> Under what conditions should an end node ever be using a multicast
> address as its source address?
> 
> I think the DI is still a little fuzzy.  It may contain link-related
> information:
> 
> 	Depending on the access technology, identifier might contain
> 	any of IP address, link-layer address, switch port number,
> 	etc. of a device.
> 
> But since the access request comes from the end-node itself, there are
> a number of serious problems:
> 
> 	- How does the end-node know the right link-layer information
>           to insert?  In some cases it may (its own MAC address,
>           perhaps), in other cases it might (its own telephone number
>           or E.164 address, though it probably cannot or should not
>           guess at the numbering plan at the other end of the link),
>           and in others it almost certainly cannot (the switch port).
> 
> 	- Why should the PAA trust the end node to insert the right
>           DI?  Since this is the 'only' authentication to occur, and
>           succeeding grants full network access to the client,
>           couldn't the client lie about the DI in order to get access
>           on a "privileged" subnetwork?  (I know; this veers off into
>           authorization territory, but it's fundamental to the
>           architecture.)
> 
> Is the access node expected to augment the DI on the fly?  If it does,
> then what are the implications for validating the message?  What are
> the implications for the requirements placed on parsing the contents
> of the DI at the access node (to make sure that no "unwanted" end-node
> information leaks through)?
> 
> Should such augmentation be specific or left up to implementor
> discretion?  If it's the latter, then what happens with
> interoperability?
> 
> > I don't understand how you get to this special example from
> > above mentioned two statements from the requirement draft.
> > You are making assumptions, such as use of challenge, and
> > especially in a unsecure way....
> 
> Agreed; this is a known problem with somewhat known solutions.  The
> thing that PANA brings to the table is a new threat model.  Since the
> PAA is an IP node, it makes a handy and available oracle for anyone
> trying to impersonate a PAA -- and only networking skills are
> required.  This is likely to be much easier than (say) finding a way
> to both jam a wireless access node and use that node as an oracle.
> 
> -- 
> James Carlson, Solaris Networking         <[email-masked]>
> SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
> 
>

---

From: James Carlson <[email-masked]>
Date: Fri, 15 Feb 2002 06:39:45 -0500 (EST)

Paal Engelstad writes:
> Personally, I would prefer a simple PANA protocol that works in most
> cases to a very complex solution designed to work in all different
> scenarios. We can always find situations where the PANA protocol
> will not work.

Fine; then I think it's quite necessary to limit the scope such that
it matches the problems that can reasonably be solved.  Without
knowing the exact scope of the problem that's intended to be solved,
it's rather hard to determine if the requirements are sufficient, or
if any particular solution is applicable.

> You say: "there are situations". It is not clear in my mind how
> "probable" these situations are. Is it your opinion that it is the
> general case, and by not allowing for more that binary authorization
> we will end up with a narrow niche product?

Basically, yes.  I have a very hard time imagining such a large step
backwards in functionality from current L2 mechanisms.

That's not really the point, though.  The point is more that the IETF
ought to be spending its valuable time designing things that will
stand the test of time.  If we can imagine plausible ways that a
scheme doesn't work today, should we imagine that this will get better
with time?

> for PANA and its complexity.

Understood; there's clearly a cost associated with a "does everything"
protocol.  I'm trying to clarify the requirements and goals.