Subject: RE: Concerns about draft-ietf-pana-requirements-00

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 7 Feb 2002 17:49:42 +0100

discovery mechanism.
  > > 
  > > => Who needs to invent a new discovery mechanism ?
  > 
  > Some discovery is clearly needed: my only point there is that DHCP
  > happens to have its own discovery mechanism.

=> So what? there are other mechanisms already
defined too. You don't have to do anything
new.

  > >   > 	- does not require the invention of new relay 
  > mechanisms for
  > >   >           non-local PAAs.
  > > 
  > > => No one said that we will need a relay agent, we might
  > > but it's not 100 % sure yet.
  > 
  > If DHCP can be used as experience, I think relays are likely to be a
  > necessary evil.  Otherwise, you have to assume that the 
  > access points
  > necessarily implement the 'right' AAA protocol.

=> Don't get that either. The ONLY reason for
relays is if you don't have an address with
scope beyond the link. Any other reason?

  > > => The problem is that all the arguments above boil
  > > down to an overloading philosophy which has caused
  > > MIPv4 to be linked so tightly with AAA.
  > > If You're arguing that The Dynamic Host Configuration
  > > Protocol be used for access control because
  > > they've already got a way of discovering the
  > > server... That doesn't make sense to me.
  > 
  > Not exactly; I have no particular love of DHCP.  

=> Yet you keep pushing for overloading it :)

Instead, I'm
  > questioning why so many of the PANA participants appear (to me, at
  > least) to assume the use of a new protocol first, rather than
  > exploring (and exhausting) the options available with the existing
  > protocols.  DHCP happens to be one way to elucidate this.

=> I don't share your perception of what
PANA people think. We have discussed EAP
and PIC on several account and we haven't
ruled them out. 

  > 
  > On the overloading issue, I'm still unconvinced that this is
  > necessarily and obviously a bad thing.  It's clearly the case that
  > assigning IP addresses, installing/removing filters, creating CoS
  > associations and the like are all authorization functions 
  > that depend
  > on authentication.

=> Clearly ? Some people don't see the point 
of associating address allocation with authorisation.
I don't think the association is so clear.

  > 
  > So, where does this leave us?  

=> In disagreement :)

Suppose we drain all 
  > authentication out
  > of the authorization mechanisms and PANA's authorization consists of
  > merely the boolean response proposed.  This means that (timewise) a
  > plausible exchange might be:
  > 
  > 	User               Access Point
  > 	---------          ------------
  > 	Discovery     ->
  > 	              <-   "I'm here, please do PANA"
  > 	PANA request  ->
  > 	              <-   "OK, I know you"
  > 	DHCP discover ->
  > 	              <-   DHCP offer
  > 	DHCP request  ->
  > 	              <-   DHCP ack

=> I'm still amazed by the placement of 
DHCP !
How about:

1. I've got an address and I'm here
2. Do pana
3. PANA done 
4. I've got access.

  > 
  > This leaves me confused.  How does the DHCP implementation (likely
  > separate and perhaps even located on a different node) know that the
  > user is authenticated at all?  

=> What if we don't have DHCP?? A possible scenario
in IPv6 don't you think ?

  > >   > The logical conclusion is rather odd though: MIPv4 has one AAA
  > >   > solution (perhaps warty; that's not PANA's problem), 
  > MIPv6 uses PANA
  > >   > for AAA.  Is that an improvement?
  > > 
  > > => No the conclusion is: You can always use PANA if you
  > > need it. Due to the MIPv4 mess, you don't need
  > > it if you're running MIPv4. In every other case
  > > you can use it (like IPv4 nodes that are not mobile
  > > or IPv6, MIPv6).
  > 
  > That assumes PANA deployment: the high hurdle here is adding a new
  > protocol.

=> Of course it does! why is it a high hurdle 
to install an application on my laptop, phone ...etc ?
Or do you mean for network operators.

  > > => No duplication, we're simplifying things.
  > 
  > If there's an existing mechanism in use, then this is clearly a
  > duplication.

=> The existing mechanisms do not satisfy
our needs. See the example I mentioned
earlier for details.

  > > => OK how about this:
  > > 
  > >      node ----UMTS (HLR)--- internet
  > >      node ---- PPP --- NAS----AAA
  > > 
  > > Why should an operator run two dual
  > > authentication schemes ???
  > 
  > I agree he would not want to do so.  I also agree that avoiding that
  > is an important goal.  I don't agree, though, that I can 
  > make the leap
  > from this to asserting that a new, global protocol is the 
  > only way to
  > do it.

=> New or old is irrelevant for this discussion.
We might end up using existing protocols. 
The does _not_ mean we have to use DHCP though.

  > > Do you see why we need to replace things
  > > and offer a simple solution?
  > 
  > Sure; provide more detail:
  > 
  > 	   <---end-to-end-use-of-EAP----->
  > 	                            DHCP--AAA
  > 	                           /
  > 	node --- UMTS (HLR) --- access device -- internet

=> No we will not use DHCP in all
cases. UMTS allows stateless configuration,
and proud of it :)

  > 
  > 
  > 	   <---end-to-end-EAP--->
  > 	                   ---- AAA
  > 	                  /
  > 	node --- PPP --- NAS --- internet

=> Why is PPP there again ? this might be 
a WLAN right?
I don't mind the EAP part though.

  > 
  > Thus, as I said, with suitable deployment you end up with 
  > exactly the
  > same authentication mechanism end-to-end, and thus the same
  > authentication infrastructure and the same maintenance.  

=> Because you used EAP. The rest is not relevant.
As I said (lost count) EAP is a potential
solution.

  > > 
  > > => Ok but our deployment today is likely to increase.
  > > Operators do often upgrade their systems to. 
  > 
  > You're going to have to wait for all of those old-fashioned 
  > Windows XP
  > systems to die off first.  

=> Does windows XP stop you from installing a
new application ??? I hope not.

  > We're not discussing this as an "option:" it's the user's required
  > mechanism for access to the network.  What financial good 
  > is a network
  > deployment if only a very few people can access it?

=> You're making too many deployment assumptions 
that don't seem reasonable to me. Roaming between
different access technologies is 'new' thing that 
is hardly deployed anywhere. Operators want to
spend money to deploy it...voila.

  > The example I gave (admittedly somewhat facetious but still not
  > completely unreasonable) assumed that the Frame Relay 
  > client would set
  > up his connection using an SVC and include authentication 
  > data in the
  > connection-setup message.  There's no way to send IP before the link
  > is established; only the low-level signaling messages are 
  > on the wire.

=> Ok so we can call that L2 (very special L2)
authentication.

  > 
  > I suspect that analogous situations will continue to be 
  > true on other
  > link layers in the future.  I think PANA should probably 
  > consider the
  > implications of being unable to send *any* IP frames until a link-
  > layer authentication is performed.

=> PANA does not eliminate link layer authentication.
The point is that L2 authentication has nothing 
to do with access levels or the user on the 
device. Unless of course you want to bundle 
everything on the link layer... why would you
do that ? We've already learnt from the cellular
experience that this has its limits: works 
on one link layer and does not allow roaming 
without re-authentication AND we end up with
operators having multiple authentication
infrastructures. 
So what was the reason for bundling everything
on L2 ? :)

Hesham

---

From: James Carlson <[email-masked]>
Date: Thu, 7 Feb 2002 12:30:00 -0500 (EST)

> defined too. You don't have to do anything

OK; fine.

> scope beyond the link. Any other reason?

Yes.  Think IPv4.  Or is PANA only a solution for IPv6 problems?

> => Yet you keep pushing for overloading it :)

No, I keep using it as an illustration because it seems particularly
apt.

> and PIC on several account and we haven't

Hmm.  OK.

> I don't think the association is so clear.

Yes.  Clearly.

For example, suppose an IPv4 ISP wants to grant differing sorts of
access to its customers, based on some sort of prior arrangement
(i.e., $$).  Some customers are given arbitrary addresses (IP address
pools, back-end DHCP allocation, per-port static addresses, et
cetera).  Some are given static addresses.  Some are given entire
subnets.

If authentication is divorced from address allocation, then how are
addresses properly allocated for customers of such an ISP?

Is this an unlikely usage scenario?

> 1. I've got an address and I'm here

As above, this seems to assume (at a minimum) an ISP that's willing to
hand out IP addresses to all users without bothering with
authentication at all.  Perhaps that works in the infinite IPv6
address space (I count myself as no IPv6 expert), but I fail to see
how it works in the IPv4 address space.

> in IPv6 don't you think ?

Sure, though without DHCP, you have to manually configure such things
as DNS server addresses.  Quite annoying.

In any event, is requiring the use of DHCP in order to get
authentication significantly worse than requiring the use of some
other protocol identified as PANA?  Why would this be the case?

> Or do you mean for network operators.

The oft-quoted zillions of PCs running out-of-date software is usually
an issue for new protocols.  This is the issue for obsoleting existing
link-layer authentication and replacing it with PANA.

> our needs. See the example I mentioned

Are you referring to the 802.1X issue?  I still don't see how the
existing mechanisms fail in a way that cannot be fixed.

> The does _not_ mean we have to use DHCP though.

No argument there.

> cases. UMTS allows stateless configuration,

DHCP is not incompatible with stateless autoconfiguration.  It's a
matter of policy rules, not protocol.

> I don't mind the EAP part though.

Wrong.  I'm showing what the access situation looks like with a
point-to-point link in it, not a WLAN.  This is a perfectly reasonable
case, and has to be considered if the goal of the working group is to
unify the authentication mechanisms used for network access.

I have never said (nor will I say) that broadcast-type media should
use PPP.  They should not.

Thus, we end up with PPP carrying EAP and, in other cases, PANA
carrying EAP.  Isn't this precisely the problem that PANA was supposed
to fix?  I'm arguing that this is a non-problem and doesn't need to be
fixed.

> As I said (lost count) EAP is a potential

No, by the requirements document, it cannot be a possible solution for
PANA.  EAP is an authentication protocol.  PANA is merely a carrier
for such protocols, as described in section 4.1.1 of the requirements
draft:

   PANA MUST NOT define new security protocols or mechanisms. Instead 
   it must be defined as a "carrier" for such protocols. PANA MUST 
   identify which specific security protocol(s) or mechanism(s) it can 
   carry (the "payload").

I agree that carrying EAP over PANA makes sense from many perspectives
and likely helps fix a number of existing problems.  That still
doesn't quite answer the question of what PANA really is.

> spend money to deploy it...voila.

No, I'm not doing any such thing.  What I'm pointing out is that where
there are existing authentication mechanisms, those will have to be
supported.

> device.

Yes, that's the crux of the issue.  Does PANA actually have anything
more to do with "users" than does existing link layer authentication?

I'm arguing that it does not.  Mere existence of an IP address on a
network does not imply the cardinality of humans behind it: there may
be zero, one, or very many users.  This has always been true with link
layer authentication (though much deployment-related handwaving is
done around the problem), and it's just as true for PANA.

Given that they're really semantically equivalent, why separate them?

> Unless of course you want to bundle 
> do that ?

I'm not sure I understand that.  What does "bundl[ing] everything on
the link layer" imply?  Certainly, I do not want application issues
(DNS server addresses, home page URLs, time zones, et cetera) solved
by the link-layer.

> We've already learnt from the cellular

I'm arguing that the issue you're raising is quite separate from L2
authentication and PANA: that issue is caused by the use of disparate
authentication protocols ('methods') that run *over* these
mechanisms.  A fully agree that unifying these (or at least minimizing
them) is a helpful thing to network operators.

On the other hand, minimizing the transports used solves nothing in
particular.  It perhaps helps some implementors and probably hurts a
few others.  It does *not* by itself in any way address the multiple
authentication infrastructures problem.

The analogy is to IP itself: IP's bits look slightly different on
every medium.  On some, it requires extra headers.  On others, it
requires manipulation of the data itself.  This isn't a bad thing.

> So what was the reason for bundling everything

Perhaps not surprisingly (;-}), I think that PPP's architecture is
roughly correct.  Authenticate, then allow IP address allocation.

-- 
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