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

From: James Carlson <[email-masked]>
Date: Tue, 5 Feb 2002 09:38:36 -0500 (EST)

I have number of concerns about the requirements draft; I'll try to
stick to just the technical ones here.  (There are some nontechnical
nits -- such as the use of strange, non-ASCII, non-ISO characters --
which I'll forward to the editor.)

> Abstract 
[...]
>    802 links), some of these protocols are also sub-optimal (e.g., PPP 
>    due to its mandatory framing which is not always needed). The goal 

This part doesn't make sense.  Framing is a fundamental requirement of
the network layer.  No matter *what* you use for the physical and
datalink layers, you need to have datagrams at the network level.  IP
won't work any other way.

In addition, PPP is designed to work *with* existing underlying
physical layer framing, if present.  In the cases where it's present
(AAL5, HDLC, X.25, Frame Relay, L2TP), PPP does not add any additional
"mandatory" framing.  In the cases where it's absent, PPP on that
particular physical layer is defined such that it includes the
necessary framing.

I'm not sure what you might be referring to here, but systems and
specifications that ignore this important detail (such as those that
might errantly pass raw AHDLC over GRE tunnels) are quite simply
broken.

>    where the agent might be a client of the AAA infrastructure. The 
>    protocol should be independent of the underlying access-type and not 
>    overloaded with other aspects of the network access (e.g., framing). 

Again, it's only the definition of PPP on a given physical medium that
specifies a particular framing.  The authentication bits have no
interaction with this at all.

(This probably isn't a significant point, since, regardless of what
the specific question might be that PANA answers, I don't think that
PPP is the right answer.)

> 1. Introduction 
[...]
>    The most widely used protocol for authenticating clients is the PPP 
>    [PPP]. This protocol can run on various access types, but it is not 
>    limited to authenticating the clients. It also provides mandatory 
>    PPP framing. Since framing is already supported by certain link 
>    types, having to use this extra framing creates sub-optimal network 
>    access solutions. 

As above, I think this is an error.  There's no extra framing
involved.

If you were to substitute "tunneling" for "framing," then I'd be in
agreement with you.  Unnecessary use of tunneling (e.g., PPPoE) is a
mistake that PANA should solve.  Framing isn't (or shouldn't be) the
issue.

> 3. Terminology 
[...]
>    PANA Client (PaC) 
>     
>          The entity wishing to obtain network access from a PANA  
>          authentication agent within a network. A PANA client is 
>          associated with a network device and a set of credentials to  
>          prove its identity within the scope of PANA.  

And, perhaps, depending on the actual authentication algorithm in use,
a verifier so that the PaC can validate the identity of the PAA.

>   4.1.2. Authorization, Accounting and Access Control 
>  
>    In addition to carrying authentication information, PANA MUST also 
>    carry a binary result (i.e., success or failure) of authorization 
>    for network access to the PaC. Providing finer granularity 
>    authorization is outside the scope of PANA. 

Perhaps it would be better to say that "authorization is a non-goal of
PANA" rather than saying it's out of scope.  Would we reject a
solution because it *does* provide such features?

> 4.3. Interaction with Other Protocols 
>     
>    PANA MUST NOT handle mobility management of the PaC. But, it MUST be 
>    able to co-exist and not interfere with various mobility management 
>    protocols, such as Mobile IPv4 [MIPV4], Mobile IPv6 [MIPV6], fast 
>    handover protocols [FMIPV4, FMIPV6], and other standard protocols 
>    like IPv6 stateless address auto-configuration [ADDRCONF] (including
>    privacy extensions [PRIVACY]), and DHCP [DHCP]. It MUST NOT make any 
>    assumptions on the protocols or mechanisms used for IP address 
>    configuration of the PaC.  

I think this section is the most confining and probably the least
necessary.  For example, this section appears to rule out simple RFC
3118-like extensions to DHCP that would otherwise fit the bill of the
other PANA requirements.  It also seems to rule out possible
extensions to Mobile IP, such as a "please give me just a local
address; I don't need to contact a Home Agent" option.

In other words, if the solution were presented as a simple extension
to DHCP, would the PANA working group participants reject that
solution on the basis that it makes some assumptions about the IP
address configuration?  If so, why?

Perhaps part of my confusion here is defining the scope of the
problem.  If you are using Mobile IP (of any flavor), do you really
want or need PANA?  I would argue that you do not want PANA; that the
existing mechanisms solve the existing problems just fine.  If you are
using PPP, do you want or need PANA?  Again, I think the answer must
be "no," because the existing mechanisms work.

Thus I think we come down to the possibly controverial core of PANA:
it appears to me to be intended to serve as the general-purpose
replacement for 802.1x that serves as well to work on all Ethernet and
Ethernet-like multiaccess media without invoking Mobile IP's (often
unneeded) goal of transparent IP mobility.  I think this is probably
general goodness, but it needs to be more clearly distinguished where
PANA is and is not intended to be used.

One of the goals expressed by this section appears to me to be that
authentication should by rights be divorced from authorization.  I
don't think I fully understand that desire.  From an abstract "purity
of concept" level, it perhaps makes some sense.  But from an
implementation and operational standpoint, I don't see how it's
necessarily a good thing or even at all possible.

>   4.5.3. Denial of Service Attacks 
>    
>    PANA MUST be robust against a class of DoS attacks such as blind 
>    masquerade attacks through IP spoofing that swamp the PAA in 
>    spending much resources and prevent legitimate clientsÆ attempts of 
>    network access. The required robustness is no worse than that for 
>    TCP SYN attack. 

I don't think that's sufficient.  Because PANA is a carrier for
authentication protocols, and authentication necessarily involves
computational complexity far in excess of that required for TCP, it's
particularly vulnerable to attack.  I also think that at least part of
the issue falls on the design of the authentication protocols carried
by PANA and is thus out of scope.

The in-scope issues seem to me to be:

	- How are PAAs protected against attack?  The logical place
          that PANA can affect this (without becoming too intimate
          with the authentication protocols themselves) is in the
          discovery stage.  Thus, discovery likely needs to be
          throttled by the PAA itself.  Some recommendations are might
          be necessary there, but I suspect that the general problem
          is intractable.  (If you start slowing down discovery, how
          do you distinguish among requests from unknown but valid
          clients and requests from unknown and invalid attackers?)

	- How are PaCs protected against attack?  This appears to be a
          lot harder.  Because the relationship isn't quite symmetric,
          a PAA isn't affected by the presence of a rogue PAA on the
          same network, but the PaCs certainly are.  PaCs can be
          attacked by compromised or bug-ridden PAAs.

	- Does any of this actually matter when a multiaccess network
          itself can be trivially (or inadvertently) attacked?

-- 
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: "Alper Yegin" <[email-masked]>
Date: Tue, 5 Feb 2002 20:57:37 -0800

Hi Jim,

Thanks for the comments.

> which I'll forward to the editor.)

Yes, I got them :)

> particular physical layer is defined such that it includes the

So, let's see if I'm understanding this right:
- can we use a strip-down PPP just to get a client authenticated
  and authorized for network access? (as you said framing is optional.
  We can also drop other goodies like IP address config, etc.).

  Can I run PPP over WLAN and when the data traffic is flowing
  there would be zero additional bytes due to PPP?

> interaction with this at all.

The argument was that authentication of PPP is good and useful, but
we don't want to live with the mandatory PPP framing.... But now
you are saying it is not really mandatory...

> PPP is the right answer.)

We seem to agree but for different reasons. Ours have been the framing
issue. What is yours?

> a verifier so that the PaC can validate the identity of the PAA.

Right. Mutual authentication.

> solution because it *does* provide such features?

Authorization is not outside teh scope. Finer granularity authorization
is. Also I don't think "outside the scope" means "MUST NOT".

> address; I don't need to contact a Home Agent" option.

So, you are saying instead of using "MUST NOT", we should use
"outside the scope" in case the PANA turns out to be an extension
of one of these protocols? (MUST NOT might be interpreted as
extensions of these protocols are prohibited as well?)

> address configuration?  If so, why?

Yes. Unless someone shows this is the only way, I rather want to
see a solution that can accomodate IPv6 address autoconfiguration,
and other methods.

> existing mechanisms solve the existing problems just fine.

Are you referring to "Mobile IPv4 with mandatory Foreign Agent
authentication"?
Then this would work, but I rather not say "the solution is to use Mobile
IPv4".
A simpler and more modular solution is better.

>  If you are

The text shouldn't be suggesting that PANA does authentication,
but not authorization. Does it?

>           itself can be trivially (or inadvertently) attacked?

Interesting points..... to think about.

Thanks Jim,

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 6 Feb 2002 09:14:36 -0500

> We seem to agree but for different reasons. Ours have been the framing

I guess "framing" and "encapsulation" are not clearly distinguished in
the above discussion, and they should be distinguished.

HDLC-like framing (RFC 1662) is not mandatory for PPP.  But PPP
encapsulation is mandatory for PPP.

Yoshihiro Ohba

---

From: James Carlson <[email-masked]>
Date: Wed, 6 Feb 2002 10:31:03 -0500 (EST)

>   and authorized for network access? (as you said framing is optional.

No.  Framing is *not* optional.  PPP's defined framing is optional.
If the underlying layers present an interface that is already framed,
then PPP framing isn't used.

I strongly suspect that you're using the word "framing," when you
really mean either "encapsulation" or simply "overhead."

>   We can also drop other goodies like IP address config, etc.).

You can omit IP address negotiation (it's not "configuration" --
merely negotiation) if you like.  It's generally a poor idea to do so,
but you're free to do it if you have a need to.

>   there would be zero additional bytes due to PPP?

Actually, you can go negative: enable VJ header compression.

> you are saying it is not really mandatory...

No, I'm saying that PPP's framing (defined in RFC 1662) is not
necessary if the underlying interface is already framed.  For example,
see RFC 1973.

> We seem to agree but for different reasons. Ours have been the framing

PPP provides an inherently point-to-point interface.  This is by
design.  If you have a multiaccess subnetwork (e.g., Ethernet), then
you're certainly not using a point-to-point model.  In particular, you
have arbitrary peer-to-peer relationships on that network (which, to
emulate with PPP, would require either a full mesh of point-to-point
links, or the use of a designated router) and you likely have the
options of broadcasting and multicasting (depending on the exact
technology used).

In other words, it's a really bad fit.  The problems that occur (as I
said before) are as with PPPoE: multicast suddenly requires needless
packet replication on the same network, because there's no general way
to guarantee that each of the PPP links tunneled on that one
subnetwork is a member of the same groups (or even in the same
multicast routing domain) and because the design gets seriously
baroque when you have to have IP tell PPP about group membership and
then have PPP (somehow) relay that information through PPPoE to the
Ethernet driver below.

The *overhead* issue is a different one, and probably only somewhat
less significant.  The one case where it's plainly a problem is that
there are a very large number of horribly misconfigured firewalls
(security == block all ICMP messages) that break Path MTU Discovery
and thus make MTUs other than 1500 problematic on the Internet today.

> Right. Mutual authentication.

As an aside, and not that it really matters, but mutual authentication
generally doesn't happen.  PPP has had the ability to do mutual
authentication from day 1, but the most widely deployed versions of it
have steadfastly refused to support more than unidirectional
authentication.  What's more, ISPs seem to be singularly uninterested
in the concept: it means more information needs to be given to
customers, and is thus a support burden when those customers say,
"huh?"

> is. Also I don't think "outside the scope" means "MUST NOT".

By saying "outside the scope," the text is saying that proposals will
be judged without regard to this support and I think it also implies
that between two otherwise equivalent protocols (one which does and
one which does not have finer-grained authorization), the group would
prefer the lesser.

Perhaps it's just my misunderstanding of the wording, but the way I
read this, there's a strong preference for a solution that involves a
new protocol to do authentication only.  I don't think that should be
done in a requirements document.

> extensions of these protocols are prohibited as well?)

Yes.

> see a solution that can accomodate IPv6 address autoconfiguration,

I don't follow that at all.  In what way does draft-ietf-dhc-dhcpv6-22
inhibit the use of stateless address autoconfiguration?

Why would invention of an entirely new protocol here be a good thing?

> Are you referring to "Mobile IPv4 with mandatory Foreign Agent

RFC 3012, I believe.

> A simpler and more modular solution is better.

That's not at all what I'm saying.  I'm saying that *IF* you're
*ALREADY* using Mobile IP, *THEN* there doesn't appear to be any need
for PANA.  The same is true for PPP.  If you're already using that,
then you don't need PANA.  In both cases, you already have defined
mechanisms for authenticating the link, and additional mechanisms
aren't really needed.

In other words, I'm trying to infer the scope of PANA, since the scope
is not really very well defined.  I believe that the scope should be
limited to just the cases where *no* other solution is available.

> but not authorization. Does it?

By "authorization" here, I'm referring to the finer-grained
authorization referred to above.  In other words, why would a solution
that merely authenticates and returns a boolean for authorization be
better than one that returns an authorized IP address, authorized QoS,
and perhaps other data?

Either the draft is unclear on the intent, or I don't understand the
desire to force a wedge between PANA and address allocation.  That
part in particular doesn't seem to me to be a practical goal.

> the above discussion, and they should be distinguished.

Right.  They're not the same thing at all.  Per RFC 1661:

2.  PPP Encapsulation

   The PPP encapsulation is used to disambiguate multiprotocol
   datagrams.  This encapsulation requires framing to indicate the
   beginning and end of the encapsulation.  Methods of providing framing
   are specified in companion documents.

   A summary of the PPP encapsulation is shown below.  The fields are
   transmitted from left to right.

           +----------+-------------+---------+
           | Protocol | Information | Padding |
           | 8/16 bits|      *      |    *    |
           +----------+-------------+---------+

> encapsulation is mandatory for PPP.

Right.  Is it merely the per-packet overhead of encapsulating packets
inside PPP that's at issue?  If so, then that's what should be said.
(And, for what it's worth, I agree, though I think it's probably the
lesser of the arguments against using PPP for this sort of purpose.
PPPoE is a good example of what we should avoid doing.)

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 6 Feb 2002 09:43:34 -0800 (PST)

Hello Chairs/Folks,

I was trying to put together a list of items we need
to revise on the draft but reading the recent threads
and some others I'm getting confused by the ">>>",
replies over replies and who is saying what. 

Can't we implement some scheme just like in the AAA
WG, where if someone wants a correction (or have an
issue) to the draft he sends something like (this is
from the actual AAA mailing list):

"Issue : Changes to state machine for ASR/ASA messages
Submitter name: Bob Kopacz
Submitter email address: [email-masked]

Date first submitted: 02-06-2002 
Reference: 
Document: base-08 
Comment type: Technical 
Priority: 1 
Section: 8.1
Rationale/Explanation of issue: 

  I believe there is an error in the "Authorization
Session State
  Machine", in section 8.1 of the base draft, in the
1st state machine
  which represents the case where the server maintains
session-state."

Before somebody raise the issue...No, we still can
discuss verything freely on the maling list, this is
just for the design team to work on all the issues in
a structured way.

Reinaldo

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 6 Feb 2002 09:43:19 -0800 (PST)

Hello Chairs/Folks,

Reinaldo

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 6 Feb 2002 15:36:07 -0800

Jim,

> necessary if the underlying interface is already framed.  For example,

(in response to all above). It looks like this is a terminology issue (I had
it wrong). more on this at the far end of this message.

> options of broadcasting and multicasting (depending on the exact

This is a very good point. We need to capture this in the req. draft.

> customers, and is thus a support burden when those customers say,

[side response: story is different now. With ISPs, when you dial a number,
you know who is on the other side (your trust in telco?). But now when you
walk into
a shopping mall, you don't know whose access point your WLAN client
associates with]

> one which does not have finer-grained authorization), the group would

To me, if feature X is outside the scope, that means if a solution
doesn't provide X, it's still an acceptible solution. But that doesn't
mean that we will completely disregard X support. When other things
are equal, the one that supports X might be preferred. IMHO.. So,
if the current language doesn't reflect that, can you please propose
a text?

> done in a requirements document.

It doesn't have to be a brand new protocol. If one can illustrate how
an existing protocol can be used as is, or after modification, this  might
be
acceptible too (IMO).

> > extensions of these protocols are prohibited as well?)

Will fix that.

> Why would invention of an entirely new protocol here be a good thing?

OK, I think I see your point.So, Jim, if you can show us one can use
dhcpv6 to just get authenticated with the network (and authorized)
but not necessarily get IP address, etc., then you can propose this
as a solution. You have to make sure the client can still use manual
IP address configuration, or address autoconfiguration, if it wants to.

> mechanisms for authenticating the link, and additional mechanisms

- If a network has already deployed Mobile IPv4, or PPP, yes they don't
have to deploy PANA  on that network.
- The solution of PANA WG should not be "deploy PPP or Mobile IPv4 in your
network"
as these have lots of extra baggage and constraints. (I know you are not
suggesting this,
I'm just saying..)

> better than one that returns an authorized IP address, authorized QoS,

It is not better, but it is sufficient. Does the text suggest we think
a protocol that barely satisfies the requirements is better than others
that go beyond? Maybe we are using wrong language in the text, if this
is your understanding.

>    transmitted from left to right.

OK, we got it. The terminology was off.. We'll capture the above, and more
importantly the non multi-access aspect of PPP.

> PPPoE is a good example of what we should avoid doing.)

Thanks!

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 6 Feb 2002 19:20:23 -0500

On Wed, Feb 06, 2002 at 03:36:07PM -0800, Alper Yegin wrote:

[...]

> This is a very good point. We need to capture this in the req. draft.

Since 802.1X can solve that problem, I don't think that thing can
really justify the need for PANA.  In addition, since this part looks
like problem stement, then it would be better to move it in the usage
scenario I-D and this document would be better to focus on the actual
requirements part.

> a shopping mall, you don't know whose access point your WLAN client

I agree.  The possibility of rogue AP is one of the important issues 
in WLAN and that justfies the need for mutual authenticate.

[...]

> have to deploy PANA  on that network.

If a network has already deployed Mobile IPv4 with FA CoA mode or PPP
without a mobility management protocol, they may not have to deploy
PANA on that network.  In other cases, PANA is needed to solve the
problems such as intra-domain inter-technology handoff as described in
the usage scenarios I-D.  

Thanks,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 6 Feb 2002 18:45:19 -0800

Yoshihiro,

> really justify the need for PANA.  In addition, since this part looks

But we are not trying to identify what problems are not solved by any
of the current solutions. As you know, in the requirements draft we are
taking people's attention to some deficiencies of the existing solutions.
This is one of them.

> scenario I-D and this document would be better to focus on the actual

If you want to put this in the scenarios draft as well, fine. But this
already
has a place in the requirements draft. We are already talking about
deficiencies of PPP and 802.1X.

alper

---

From: James Carlson <[email-masked]>
Date: Thu, 7 Feb 2002 10:47:35 -0500 (EST)

> if the current language doesn't reflect that, can you please propose

Could the requirements say something like this?  "The minimum
requirement for PANA is a protocol that provides mere confirmation of
identity.  It MAY provide finer-grained authorization."

> IP address configuration, or address autoconfiguration, if it wants to.

From draft-ietf-dhc-dhcpv6-23:

18.1.1. Creation of Solicit messages
[...]
   The client
   MAY include addresses in the IAs as a hint to the server about
   addresses for which the client has a preference.
[...]

In other words, all that the client has to do in order to use a
manually-configured IP address with DHCP is to include that address in
its request to the DHCP server.

Obviously, the policy on the DHCP server must be set such that it
allows the client to choose that address.  That, of course, is no
different from the administrative situation without DHCP: the
manually-configured address must be one that the administrator of the
nearest router is willing to permit.  In both cases, the client has to
have a prior arrangement with the network administrator in order to
use a manually-configured address.

As noted by another contributor, DHCP may well be needed for other
reasons, such as configuration of DNS server addresses.

> as these have lots of extra baggage and constraints. (I know you are not

Agreed; I don't think this group should argue for deploying solutions
that are known not to work exactly right.

On the other hand, I do think that the current existence of link-layer
authentication in some circumstances is itself a limitation on the
scope of PANA.

> that go beyond? Maybe we are using wrong language in the text, if this

Reading through the lines of the recent postings, that seems to me to
be the understanding of several contributors.

I think it's pretty important to state the relationship between PANA
authentication and authorization as clearly as possible in the
requirements, because we seem to be approaching the problem with
different solutions in mind.

> importantly the non multi-access aspect of PPP.

OK; thanks.

---

From: Jacques Caron <[email-masked]>
Date: Thu, 07 Feb 2002 22:43:59 +0100

Hi,

>options of broadcasting and multicasting (depending on the exact

That's only if you look at things from a L3 perspective. Switched Ethernet, 
as well as Wireless Ethernet does effectively isolate each device connected 
at the end of a point-to-point link between the switch/AP and the "client". 
And that's where 802.1x comes in for authentication on that link.

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: James Carlson <[email-masked]>
Date: Thu, 7 Feb 2002 17:03:45 -0500 (EST)

> And that's where 802.1x comes in for authentication on that link.

Would that still be the case for broadcasts?  If there's an L3
authentication mechanism that authenticates the "user" (whatever
*that* is) to the IP access router behind the 802.1x AP, then how does
the AP know which links belong to which broadcast domains so that it
can segregate the traffic?  Does it sniff at this new L3
authentication exchange?

How about multicasts (using, presumably, IGMP snooping or *shudder*
GARP)?  Where's the address allocation coordination among the ISPs
behind the access routers?  When someone sends a packet to 224.0.0.1,
which systems see it?

Unless I'm seriously misunderstanding something here (always a
possibility, I suppose), I think there are a lot of unanswered
questions with draft-tsirtsis-eap-over-icmp-00.

---

From: Jacques Caron <[email-masked]>
Date: Fri, 08 Feb 2002 00:21:44 +0100

Hi James,

I think you lost me here. I was trying to make the point that even Ethernet 
and Wireless Ethernet look like point-to-point links if you take them at 
the right point, i.e. the edge device, which here happens to be a L2 
device, which can do authentication using 802.1x, which is basically 
exactly the same as what happens with PPP, with just a different 
encapsulation/framing/L1.

Anything that happens after that (at L3 and up) would be after the client 
is authenticated, and is a completely different issue (even though adding 
EAP auth -and all associated AAA back-end stuff- to IGMP might not be a bad 
idea eheheh).

That's where somebody will probably jump in saying "but that's where we 
could use PANA to avoid adding another EAP-over-x encapsulation", and 
that's where I will reply "but then it's not network access that PANA is 
authenticating for anymore" and "how will the client know which protocol 
it's receiving an authentication request for?".

Jacques.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 8 Feb 2002 10:32:49 +0100

> Right.  So solutions that work well only with IPv6 would seem to be
  > ruled out.  Is that the case?

=> Well, of course, but if 'works well'
means replicate the PPP model then 
I can't answer that.

  > > => No, but clearly the entire business model
  > > is based on lack of addresses. Think IPv6 as
  > > well :)
  > 
  > Right.  But does this mean that PANA should not support 
  > IPv4?  Or that
  > it should not work well there?  What exactly are you saying?

=> I'm saying that the IPv6 model is drastically
different form the one you mentioned. While I
do not have a proposal that will work for
both models, I am sure of one thing: We shouldn't
distort the IPv6 solution just because the current
IPv4 is based on cruft. But I understand 
that we need to support both, I just don't
know what the best way is yet.

  > > => I haven't been spending a lot of time 
  > > thinking about how to solve it for IPv4, 
  > > but can't you allocate the address for a short
  > > period and refuse renewal unless the request
  > > is authenticated ?
  > > So: 
  > > 
  > > - get address for short period (20 seconds maybe)
  > > - Do PANA: get LSA that can be used with DHCP servers
  > > - renew address lease.
  > 
  > For IPv4, this has DOS problems, I believe.  The attacker is able to
  > acquire IP addresses without authentication.

=> Sure, I was trying to give an example, don't
know if it makes any difference if we reduce the
initial time. 

  > This is certainly not true in the US.  All of the ISPs that serve my
  > location (save one: AOL) supply public IPv4 addresses.  I'd 
  > be dead in
  > the water without that, as I'm using IPsec.  (That private addresses
  > are popular elsewhere is an interesting issue ...)

=> Well it's not popular :) people _have_ to use it.

  > > => Except for installing PANA on my laptop
  > > and having my WLAN driver (which doesn't need 
  > > PPP) what else needs to be obsoleted?
  > 
  > If unifying the authentication technologies relies on wide 
  > deployment
  > of PANA (which I dispute) and if PANA duplicates the role of
  > link-layer authentication (which I assert), then it's 
  > necessarily the
  > case that obsoleting the existing link-layer authentication 
  > mechanisms
  > in favor of PANA needs to be a goal, because you're left with
  > unnecessary duplicate otherwise.

=> This is the type of transition period (or initial
deployment) that we need to address when considering
IPv6 too. A gradual phasing out of existing mechanisms
is needed of course. But in this case, it is much
simpler. the operator simply needs to have a PAA
and gradually migrate its users to PANA. 
If this doesn't make business sense, then PANA 
will not be deployed, so my  take is: Let them
decide. There is zero point in restricting 
PANA's role here in IETF. At the end of the
day, operators will do what they want regardless.

  > 
  > Thus, if obsoleting these mechanisms isn't a goal of PANA, 
  > then either
  > unification doesn't happen or the already-muddied authentication
  > waters become denser.
  > 
  > It doesn't quite matter that *you* aren't running PPP on 
  > your laptop.
  > The fact of the matter is that providers do have PPP users.

=> So they gradually move them. 

  > As posted before:
  > 
  > http://search.ietf.org/internet-drafts/draft-congdon-radius-
  > 8021x-17.txt

=> I hadn't seen it, I'll read it.

  > No, that's not it.  The handling of IP addresses within a 
  > DHCP server
  > is a matter of policy.  If the client wants a particular address
  > (perhaps one that it has manually configured or acquired 
  > through other
  > means) and if the server permits it, then it can use that 
  > address with
  > DHCP.  One is *not* required to allocate IP addresses in a DHCP
  > server; allocation is a matter of policy.

=> OK, then I'm arguing that if you don't need 
DHCP for configuration, you don't buy the server. 
In IPv6 this is possible.

  > > => Well The scenario I'm thinking off involves roaming
  > > between link X and link Y (different technologies). 
  > > This means that PPP can not be assumed.
  > 
  > But it can't be assumed away, either.  

=> Of course it can! I just gave you an example
with cellular & WLAN. Where is PPP???

In cases where PPP 
  > is present,
  > the drawing that I gave is accurate.  EAP can run over PPP, and the

=> Great, I don't assume PPP, and I'm sure you're
aware that in my scenarios there is _no_ 
signle authentication scheme.

  > I'm assuming it into existence for the purpose of argument.  If it
  > exists, then it duplicates EAP on PPP.  This is necessarily true
  > because PPP doesn't exist on all link layers.

=> Basically, you do not want to accept that we should 
replace a mechanism that only works in some 
cases with one that works in all cases. Your 
reasons are essentially deployment issues. 
Going by these arguments we should never move
forward. I will just have to agree to disagree
with this philosophy.

  > How is the abstract notion of a "user" attached to any given IP
  > address?  It seems that you believe this to be a fundamental
  > requirement of PANA, and yet the current requirements draft says
  > something rather different (section 4.1.1 again):
  > 
  >    PANA MUST authenticate a PaC for network access. A PaC can be 
  >    identified by the credentials (identifier, 
  > authenticator) supplied 
  >    by one of the users of the device or the device itself. 
  > PANA MUST 
  >    only grant network access service to the device 
  > identified by the 
  >    DI, rather than granting separate access to multiple 
  > simultaneous 
  >    users of the device. Once the network access is granted to the 
  >    device, the methods used by the device on arbitrating 
  > which one of 
  >    its users can access the network is outside the scope of PANA. 
  > 
  > Where is the PANA requirement that "users" be the entities that are
  > authenticated?

=> First this is a 00 draft. Not withstanding that: 
what identity do _you_ think should be sent to
the authenticator? The entity that is paying 
for the service or some other entity ?

  > 
  > The draft requirements do not quite support this position.  The
  > working group charter has this:
  > 
  >   - A device (on behalf of a user) to authenticate to an 
  > agent in the
  >     local network.

=> Of course the device does it on behalf of the
user. I'm not assuming that the user will stand 
and shout until he gets heard by some neural network
in a RADIUS server. The statement is superfluous.

  > 
  > In truth, I find that to be a bit vague.  Which user?

=> The one paying for the service. The one that
the ISP will hold responsible if abusive material
are sent from that device. 

  > If you replace the credentials on a link layer authenticator, is it
  > still the same link?  I argue that it is not the same link: by
  > replacing the SIM card, you're changing the identity of the link.

=> You're really twisting my claims. The SIM card
is NOT a link identifier. It's a USER identifier. 
You can wish to think of it as a link identifier
and perhaps think the same of a NAI, but that's
not the case. 
SIM: SUBSCRIBER Identity Module.

  > 
  > This is not the same as changing the identity of the human 
  > behind the
  > phone.  I can lend you my (hypothetical) GSM phone without 
  > pulling out
  > the SIM card.  Or, I can use multiple SIM cards myself 
    (say, one for
  > work and one for play).

=> Obviously, there is an assumption that if you 
give your network password to people then you
are allowing them to assume your identity and 
authority as far as the network is concerned. 
Same as giving your secret key ...etc 
We can get philosophical about this but really 
the point is this: You (as a user) are responsible
for the secret between you and your operator. 
If you willingly give it away, it's your problem.

Of course you can have more than one identity, as 
far as your operator is concerned, even without
the operator's knowledge...so what? It doesn't
reflect on how other humans perceive you (as two
different people) unless you hide the mapping
between your identity and real name. So why 
is this relevant to the ISP or to our discussion ?
Your identity still means 'user' as far as the
ISP is concerned.

  > In any event, what's being authenticated there is not the 
  > user.  It is
  > the link.

=> If you choose to change the definition of 
existing standards that's your choice, but 
according to existing standards this statement
is obviously wrong.

Hesham

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Feb 2002 08:47:30 -0500 (EST)

> with cellular & WLAN. Where is PPP???

I thought that the point of PANA was to provide an all-encompassing
authentication transport for all network access.  Is this no longer
the case?  Or are you asserting that ISPs don't have to support
authentication on existing point-to-point links?

My point here is that PPP does exist.  Assuming PANA is to be the
all-encompassing network access protocol, the effect of PANA on PPP
operation must be considered.  The fact that any one user is perhaps
not using PPP is not a reason to ignore it.

> cases with one that works in all cases.

I'm looking for existing cases where there is a hole that PANA fills.
I'm still having a very hard time finding one.

For UMTS/3GPP, as best I can tell (decent technical data is hard to
come by), PPP is used.

For wireless LANs, 802.1x is used.  For wired ones, nothing is
currently used, but 802.1x would still work.

Where's the gap?

> Your 

Deployment issues often result when there's a duplication of service.

> forward. I will just have to agree to disagree

Fine.

> for the service or some other entity ?

That's really a private matter between the authenticator and
authenticatee.  I don't see how any working group can have any effect
on such private arrangements.

To illustrate the problem, let's create a hypothetical situation.  A
service provider creates "tradeable" mobile Internet devices.  The
devices have (built into them in some way) a set of credentials that
belong to the phone itself.  Users can buy or sell these devices for
(presumably) the cost of the remaining airtime assigned to those
credentials.  Users could 'refill' the airtime allotment by paying a
fee to the provider.

Such a situation would be quite useful.  One could imagine going to
rent a car and picking up one of these devices to take on the trip,
and paying the difference in credits on return, for example.

So, for such a situation, what is the identity?  Where's the "user"
who needs to be authenticated?

> are sent from that device. 

That would appear to assume a particular deployment scenario.

> SIM: SUBSCRIBER Identity Module.

I don't think it matters what that acronym stands for.  If I plug
*your* SIM into *my* phone, does the system think that I'm still me or
that I'm now you?  If it's the former, then it's authenticating the
user.  If it's the latter, then it's authenticating the link.

Why the focus on the "user?"  I'm still having trouble understanding
why that's a significant issue at all for a *protocol*.

> Your identity still means 'user' as far as the

Or, you can just make it more general and say that the link is what's
being authenticated.

> according to existing standards this statement

Really?  What standards am I changing?

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Feb 2002 09:24:32 -0500 (EST)

> encapsulation/framing/L1.

Agreed; the modern Ethernets are indeed all physically and
topologically point-to-point links.  The problem is that at L2,
they're not.  They have L2 semantics (broadcast and multicast) that
other L2 protocols do not.

Thus, a couple of problems emerge with the multi-ISP scenario in
section 1.1 of draft-tsirtsis-eap-over-icmp-00.

	- If you have bridges between the end node and the one that
          does the actual authentication, then other nodes can see at
          least the broadcast and multicast traffic.

	- Even if you don't, and you authenticate at the first hop,
          you have to somehow tie in the decision made there into the
          identity of the broadcast domain to be used.  (Not an
          unsolvable problem, I'll admit.  VLANs would do it.)

> EAP auth -and all associated AAA back-end stuff- to IGMP might not be a bad 

ARP's probably a bigger hole ...

> it's receiving an authentication request for?".

Yes, that's the problem.  Plus, "how will the L2 devices know what
L2-specific services to enable?"

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Feb 2002 10:19:29 -0500 (EST)

> problems such as intra-domain inter-technology handoff as described in

Could you be more specific here?  What problems of intra-domain
inter-technology handoff does (or should) PANA solve?

There appear to be at least three problems at issue:

	1. The transport used for the authentication mechanism might
           be different between the two domains.

	2. The authentication mechanism might be different between the
           two domains.

	3. The authentication realm might be different between the two
           domains.

PANA clearly addresses (1).  But how does it address (2) or (3)?  Both
of these appear to be deployment issues that are outside the scope of
the working group: providers who want to allow seamless roaming
between access technologies must *choose* authentication mechanisms
that are available on all of their access links, and must set up
consistent (or identical) realms across the domains.

Does (or should) PANA attempt to solve (2) or (3)?  How would this be
done?

The issue described for (1) exists only between the two link-layer
implementations; it vanishes outside of that connection because only
the authentication data (not the transport itself) is gatewayed into
AAA.  Is solving (1) really a serious barrier to service deployment?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 8 Feb 2002 10:38:02 -0500

James,

>            be different between the two domains.

What the transport mean, such as TCP and UDP?  

Isn't "between the two domains" be "within a domain"? 
(since the scenario is "intra-domain")

Sorry for questioning to your quetion (but I think we need to save our
time to avoid unnecessary email exchange that might occur without
sharing the same view :-).

Yoshihiro Ohba

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Feb 2002 10:45:40 -0500 (EST)

> What the transport mean, such as TCP and UDP?  

Anything that carries the authentication mechanism's messages.  For
example, if you were doing EAP over UDP as your solution, then UDP is
the transport, and EAP is the authentication mechanism.  Per the
current PANA 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"). An example of a carrier would be the 
   registration request message of Mobile IPv4 [MIPV4] that carries MN-
   FA authentication extension.  

carrier == transport

> (since the scenario is "intra-domain")

An overloaded word, then.  Read as "between the two link access
technologies and their associated authentication infrastructures," if
you like.

> sharing the same view :-).

No problem.  Most of the issues seem to come down to having good
definitions.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 8 Feb 2002 11:39:54 -0500

James,

>            be different between the two domains.

carrier == transport, OK.  

> consistent (or identical) realms across the domains.

PANA clearly addresses (1).  For (2), if I interpret "two domains" as
"between the two link access technologies within the same
administrative domain of the authentication infrastructure", it would
be natural to assume that the same authentication mechanism is used
for re-authentication within the same administrative domain and case
(2) does not exist.  Otherwise, I interpret "two domains" as "between
the two link access technologies between different administrative
domains of the authentication infrastructure", then it boils down to
case (3), I think.

For (3), I guess you are talking about handoff among multiple
administrative domains of the authentication infrastructure.  If so,
optimization for (3) is out of the usage scenario of PANA.  Note that
even Mobile IPv4 AAA extention does not also deal with optimization
for (3).

> AAA.  Is solving (1) really a serious barrier to service deployment?

Sorry, I don't understand the above paragraph.  Could you 
show some example on this?

Yoshihiro Ohba

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Feb 2002 12:02:31 -0500 (EST)

[...]
> for re-authentication within the same administrative domain

Sure -- this is a deployment and policy issue.  In other words,
carriers who want switching between link technologies to work are
going to need to configure (say) EAP on Bluetooth and EAP on 802.1x.
If they don't do this, then it won't work.  PANA doesn't help in any
case: the provider who uses different authentication mechanisms on
different link technologies can just as easily deploy his network to
do the same with PANA.

> and case
> (2) does not exist.

Or doesn't exist by assumption: that is, it's left as a problem for
the carrier to solve.  PANA doesn't address it.

>  Otherwise, I interpret "two domains" as "between

The two are actually distinct, but this probably doesn't matter at
this point.

> administrative domains of the authentication infrastructure.

Multiple authentication realms: separate AAA infrastructures (for
whatever reason -- perhaps political/administrative, perhaps based on
presumed physical layer security).

>  If so,

Agreed.  So PANA really addresses only (1): the fact that today the
same EAP authentication messages are carried with different
encapsulations on different link technologies.  Why is this an
important problem and why does it need to be solved?

This issue clearly has no effect whatsoever on the ability to roam
between domains while using the same authentication methods.  That is
to say, if you're using EAP in all cases, the Bluetooth access device
can relay EAP-over-Bluetooth to the same AAA server that's used by the
802.1x access device for EAP-over-802.1x.

Where's the conflict?

> show some example on this?

Sure.  Let's take a concrete and existing set of technologies: PPP and
802.1x for Ethernet.  I can use EAP for both.

Without PANA:

  When I authenticate my PPP link, I use EAP over PPP and the NAS
  talks to a backend AAA server to authenticate my link.  I then
  disconnect and fire up my WLAN card using 802.1x and EAP.  The WLAN
  driver uses EAP -- with the same credentials -- and the 802.1x AP
  talks to the same AAA server that the PPP NAS used and authenticates
  my new link in the same way.

With PANA (of any of the IP-ish flavors proposed):

  I bring up my PPP link, perhaps without authenticating at all.  I
  then start PANA and discover a PAA somewhere inside the provider's
  network.  I then authenticate to that using EAP over PANA, and the
  PAA relays this to the AAA server.  Later, I disconnect PPP and fire
  up the WLAN card.  I acquire an IP address and search for a PAA
  (perhaps different from the first one).  I authenticate to it using
  EAP over PANA (note that I can't just reauthenticate because PANA
  may have "device identifier" data associated with my previous
  authentication, and clearly the PPP port number isn't going to be
  the same as the WLAN link number).

Where is the problem that PANA is solving?  The authentication
information (as contained within EAP) and infrastructure (defined by
the AAA deployment) are the same in both cases.  The only difference
is that (A) the packets on the wire between by node and the access
device are a little different, but not different to the AAA server and
(B) the second case doesn't exist yet and [based on my comments
before] has IPv4 address-assignment problems.

Given that the only thing PANA seems to fix is the format of the
packets between the two link-layer hosts, and given that PANA appears
to break the access decisions that the first-hop L2 device has
traditionally made, what's the argument in favor of PANA?

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 8 Feb 2002 11:37:41 -0800

Jim,

> not using PPP is not a reason to ignore it.

One effect of PANA on PPP will be this: those networks using
PPP only for its authentication will replace it with PANA. Of course
there will be lots of other access networks that still have to use PPP.
So, as you suggest, one has to define the effect of having both PANA
and PPP on the same network. But this is not something new. Just like today
you can have Mobile IPv4 (with MN-FA authentication extension,
or MN-AAA) running over PPP.

> who needs to be authenticated?

The requirements draft doesn't deal with "users". We put extra effort
to stay clear off this philosophical discussion. The requirements draft
is clear on this issue.

alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 8 Feb 2002 11:45:41 -0800

> > it's receiving an authentication request for?".

I don't understand. Why does the client have to know which protocol (I
assume
L2 protocol?) it's receiving an auth. for? If it really cares, it can look
at which
interface has recevied it and figure out the link-layer type.

> L2-specific services to enable?"

Jim, which L2-specific services are you talking about? Could you please
elaborate
what services needs to be known upon an network access authentication?

alper

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Feb 2002 14:56:46 -0500 (EST)

Alper Yegin writes:
> L2 protocol?)

No; L3.  Which L3(s) are authorized following a successful PANA
negotiation?  Suppose (as unlikely as it may seem ;-}) I have a
network access point where some non-IP protocols are used.  Following
PANA, has use of these protocols through the access provider been
authorized?  If not, do we need "PANA over Foo" for each Foo in
{world's list of L3s}?  If it *is* authorized following PANA, does it
make sense that PANA over IPv4 authorizes the use of IPv6 on the link?

> what services needs to be known upon an network access authentication?

L2 QoS marking or bandwidth control, for instance.  Suppose my L2
allows the user to request a given amount of bandwidth along with his
request for network access.  How does PANA authorize this?  Does use
of PANA imply that all users get some "nominal" bandwidth and then
upgrade following the PANA exchange?  If so, does that actually work
with existing admission control schemes?

What happens if the user isn't authorized for the level he asks, but
the network wants to give him something between that and the "nominal"
level?  Does PANA authentication fail or succeed?

Once again, I'm very confused about what it means to divorce
authentication services from the fine-grained authorizations that
these authentications often imply.  That separation seems to be a goal
here, but I don't see why it's a good thing, or how to deliver
existing services in the new regime without inventing new protocols.
(For example, I think we're going to need to have some sort of "PAA to
L2 access point control protocol.")

---

From: Jacques Caron <[email-masked]>
Date: Fri, 08 Feb 2002 20:56:33 +0100

>interface has recevied it and figure out the link-layer type.

In the context above, we were talking about EAP for IGMP, so it's not 
really L2 access.

>what services needs to be known upon an network access authentication?

Addressing. QoS. Encapsulation. Encryption. Keys. Compression. Multi-link 
bundling.

Basically, anything that can be negotiated in PPP, and a few more for other 
L2 media.

Jacques.

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Feb 2002 15:03:43 -0500 (EST)

Alper Yegin writes:
> PPP only for its authentication will replace it with PANA.

What I think (or hope) you mean to say is that those who are presently
*misusing* PPP for authentication, as with PPPoE, will replace it with
PANA.  That I'd agree with.  Those using PPP for its authentication on
point-to-point links shouldn't fall into that class.

> Of course
> and PPP on the same network.

Yes.

> But this is not something new. Just like today

Ah, but that's rather a different thing.  The PPP link is being
authenticated such that the node is granted the privilege to send and
receive IP packets to the NAS (and presumably some wider network
behind that).  Mobile IPv4 authentication is authenticating that (1)
the node is permitted to establish a tunnel to its home and (2) the
foreign agent is willing to provide the tunneling services.

There's a clear association there of authentication with particular
capabilities.

This is missing or overlapping with PANA.  With PANA, as best I can
tell, the authentication precisely duplicates the authentication
already performed on the link.  It doesn't add anything new.

> to stay clear off this philosophical discussion. The requirements draft

Other posters seem to disagree quite a bit with that, as does the
charter.  If there's some useful meaning to the distinction between
"user" and "link" authentication in this context, then I think that
really needs to be made clear in the requirements.  If, as I suggest,
there is no useful distinction at this level, then it needs to be
dropped.

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 8 Feb 2002 12:20:23 -0800

> make sense that PANA over IPv4 authorizes the use of IPv6 on the link?

I suspect upon a successful PANA exchange, all traffic is authorized.
This can be made possible by providing the mac address of the device
as the DI. (well, I guess one can also get authorized only for IPv6 by
providing an IPv6 address as the DI, I suppose. But these are really for
the solutions to define).

> L2 access point control protocol.")

I am not saying we will never need finer grained authorization to be carried
on PANA. I'm saying there are networks that don't need that level of
authorization, a solution simple enough to say "you are authorized" is
sufficient for them, and for others we can later extend PANA but we
don't want to do this today because it has lots of traps and ratholes, etc.

This is a staged approach. Not an ignorance on finer authorization.
If we get into finer authorization today, this will delay the protocol
development. And many networks can deploy this without finer granularity
authorization today.

alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 8 Feb 2002 12:27:07 -0800

Yes.

> foreign agent is willing to provide the tunneling services.

I know. Although this is not the intention, people have been seeing/using
MN-FA authentication as "network access authentication" as well. Which
is reasonable.

And have been complaining how we don't have this with Mobile IPv6.

> already performed on the link.

If the that particular link has this capability, yes.

>  It doesn't add anything new.

You might say so by just looking at that particular link, but for 
all the link-layers totality (current links and new links to come),
that's not so... 

> there is no useful distinction at this level, then it needs to be

Other posters might have different view/opinion. I'm not saying charter is
incorrect, but we paid *extra* attention to the requirements draft in this
respect. Please use the requirements draft.

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 8 Feb 2002 15:36:09 -0500

> going to need to configure (say) EAP on Bluetooth and EAP on 802.1x.

Not necessarily.  If there is PANA, L2 authentication could be null.  

> different link technologies can just as easily deploy his network to

What do you mean by "different authentication mechanisms"?, and 
how different link technologies can just as easily deploy his network to
do the same with PANA?

> important problem and why does it need to be solved?

See below.

> 802.1x access device for EAP-over-802.1x.

See below.

>   my new link in the same way.

I don't think that local re-authentication is possible unless either
(i) inter-L2 context transfer between PPP NAS and 802.1x NAS (i.e.,
the AP) is invented or (ii) a single NAS always terminates both PPP
and 802.1x connections.  That's one of the problems of the
everything-in-L2 approach we really want to avoid.

> traditionally made, what's the argument in favor of PANA?

Why should PANA make the same access decisions as the first-hop L2
device does?  Why can't we invent a new usage scenarios that are
different from the tranditional usage scenario?

Thanks,
Yoshihiro Ohba

---

From: Jacques Caron <[email-masked]>
Date: Fri, 08 Feb 2002 21:33:11 +0100

>or MN-AAA) running over PPP.

Mobile IPv4 provides a tunneling service, i.e. a L2-emulation protocol to 
another endpoint, on top of another L2 (to a local endpoint). So, it 
requires its own authentication, and the two are completely separate.

Jacques.

---

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

> I suspect upon a successful PANA exchange, all traffic is authorized.

Really?  So, after doing PANA, I should be able to send OSI or
AppleTalk?

> the solutions to define).

That seems to violate one of the other constraints: by putting the L3
address into the DI, I think you're necessarily authorizing the use of
that L3 address as a part of PANA.

> don't want to do this today because it has lots of traps and ratholes, etc.

Fine.  But for those who do want to have such finer-grained
authorization, I submit that the L2-based authentication mechanisms
are more flexible than any L3-based mechanism -- merely because
there's as yet no signaling between the PAA and the NAS.

> development. And many networks can deploy this without finer granularity

I see PANA as causing additional future work: since the fine-grained
authorization information is needed at the first L2 access node, and
since PANA doesn't necessarily put the PAA there (in fact, some
correspondents on this list are quite sure that it is not there), we
will also need a new protocol to carry authorization from the PAA to
the L2 access node *plus* some sort of security relationship between
the two.  I think that's harder.

> MN-FA authentication as "network access authentication" as well. Which

It's quite reasonable.  You then get down to the question of "what is
network access authorization?"  I suspect that the right answer is not
"an IP-based exchange with some nearby router" but rather "it depends
on the link layer in use."

> And have been complaining how we don't have this with Mobile IPv6.

Agreed.  I would strongly argue against having PANA make the end-run
around Mobile IPv6 politics.  If Mobile IPv6 needs AAA linkage (and I
agree that it likely does), then that should be defined within Mobile
IPv6, not by PANA.  There are very likely to be Mobile-IPv6-specific
authorization issues that need to be dealt with as a part of that
mechanism.

(This is very much the same as is the case with any L2-specific
issues.)

> If the that particular link has this capability, yes.

We know this to exist for PPP and for 802.  What is are the links that
need PANA?

> all the link-layers totality (current links and new links to come),

I'm still unconvinced that having one L3-based authentication actually
fixes all requirements for L2-based solutions.  Where there are gaps
(such as fine-grained authorizations, many of which are in place for
things like PPP; see any vendor's RADIUS attributes for details), L2
mechanisms will fill the voids.  Where does that leave PANA?

> respect. Please use the requirements draft.

I agree that the requirements draft is clearer here and that it agrees
with what both of us are saying, but I don't agree that there's rough
consensus, especially among those not criticizing PANA.

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Feb 2002 16:08:58 -0500 (EST)

> Not necessarily.  If there is PANA, L2 authentication could be null.  

Perhaps "could be," but at least EAP on 802.1x and PPP are existing
solutions.  And if L2 authentication is null, then existing L2
authorization mechanisms break.  Why duplicate the effort?

> What do you mean by "different authentication mechanisms"?

PANA is a carrier; it doesn't enforce the type of authentication done
among various access technologies.

>, and 

No, I'm saying that if a provider can break his network by requiring
(say) MD5-Challenge over EAP on his Bluetooth access points, but
SRP-SHA1 over EAP on his 802.11 access points, he can do the same
damage with PANA, which just *carries* the authentication protocol
messages.  That would be an example of differing authentication
methods.  He could even require some non-IETF protocol on one of them
for added perversity.

In other words, PANA doesn't appear to address the core issue:
differing authentication methods between different link layers is
causes trouble.  I'm not arguing that it should address this problem,
but rather that effects of this problem appear to be at the core of
the assumptions that create the need for PANA, and that PANA can't fix
them.

> the AP) is invented

What context transfer?  The PPP NAS and the 802.1x AP can use exactly
the same AAA service on the backend.  The same authentications take
place.  What bits of context would you like to transfer?

If you're asserting that you'd like to keep the same IP address when
switching among types of links, I don't see how PANA addresses that at
all.  In fact, PANA appears to be intentionally divorced from address
allocation.

What other context is there?  Session keys derived from the
authentication protocols?  What happens in PANA when the PAA changes?
Is redoing authentication to get new keys a problem?

If it's just the reauthentication that's a problem, then it might be
better to have a nonce-based mechanism to allow AAA disconnect/
reconnect.  In other words, the AAA server gives the client a
one-time-use password (perhaps at initial authentication time) that
the client stores.  On switching to a new session over a new link, the
client sends that password and the server does a lightweight
rechallenge to make sure that all is well.  If anything fails, drop
back to normal authentication.

Of course, I don't think that's necessary at all until it's proven
that reauthentication on switching link technologies is a significant
problem that actually needs to be solved.

> or (ii) a single NAS always terminates both PPP
> and 802.1x connections.

No; I wasn't assuming that at all.  Please re-read what I wrote.  I'm
assuming a separate PPP NAS and 802.1x AP, both of which use a AAA
protocol to access a common backend AAA server and authenticate the
links in the same way.  Why is that a problem?

>  That's one of the problems of the

What problem?

Where is the "everything-in-L2" assumption?

> different from the tranditional usage scenario?

Please describe what sorts of access decisions one could make in PANA
that could not be made by the first-hop L2 access device.  I have yet
to see any.

I'm all for invention, but I'm getting the unhappy feeling that PANA
is a solution out in search of a good problem.

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 8 Feb 2002 13:44:25 -0800

> requires its own authentication, and the two are completely separate.

No.  This is why there is an R bit in the RFC2002. Even if the mobile node
is
using a co-located care-of address (FA has no use in this case!), it has to
register
with the FA if the R bit is set in the agent advertisements. This is for
network
access! So, people are already using MN-FA authentication for this purpose.

This is what Mobile IPv6 has been missing. PANA is the right piece
for Mobile IPv6.

alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 8 Feb 2002 14:19:32 -0800

> Really?  So, after doing PANA, I should be able to send OSI or

Isn't this already what happens after PPP auth?!?

> that L3 address as a part of PANA.

Well, this way the client is authorized to use the network as long as
it uses this specific IP address as the source....

> there's as yet no signaling between the PAA and the NAS.

MIDCOM? COPS?

> the two.  I think that's harder.

See above.

> around Mobile IPv6 politics.  If Mobile IPv6 needs AAA linkage (and I

I'm afraid (guessing) the "politics" you are referring to here is way
different then
what i'm talking about. (access control vs. ownership issues?)

> authorization issues that need to be dealt with as a part of that

No....

Mobile IPv4 has the Foreing Agent as the control-point on a visited network.
Even if the MN is using a co-located care-of address and doesn't need
anything
from FA, the FA can force (or inform) the MN that it has to get
authenticated
by the FA first (R bit in the agent advertisement says that).

How can we get the same effect as the Mobile IPv4? Well, we
can deploy Mobile IPv6 with PANA. All L3 solution.

> We know this to exist for PPP and for 802.  What is are the links that

Bluetooth, as Jacques was suggesting. And maybe others that I don't know.
But you can definitely argue that all of them can easily get this fixed at
L2,
by carrying EAP. And you can even say all the future L2s (until the end
of world comes :) will have their own.... But doesn't this itself say
something?
Why duplicate the work??? Why not use abstraction and level this up to IP?
We are trying to break this trend: every L2 has its own EAP carrier. But you
seem to like it.

> fixes all requirements for L2-based solutions.  Where there are gaps

It's not going to fix "all requirements for L2-based solutions" today, but
it will fix "basic requirements for all L2s" initially, and gradually
move towards "all requirements for L2-based solutions"...

> consensus, especially among those not criticizing PANA.

Oh, well....

alper

---

From: Jacques Caron <[email-masked]>
Date: Fri, 08 Feb 2002 23:14:02 +0100

>access! So, people are already using MN-FA authentication for this purpose.

I have to admit I'm not familiar with Mobile IPv4 deployments (or even 
implementations, or the protocol itself), but I have to admit that a quick 
glance through RFC2002 doesn't make me feel like this will work at all 
times, given the number of SHOULDs relating to that bit :-/

Also, since this is a local requirement, it would seem this is just a hack 
to compensate for the lack of authentication on the local link (RFC2002 is 
quite anterior to EAP and even more to 802.1x). Now that this exists in 
most cases, I'm not really sure that thing is needed anymore.

Any hints of contexts where this is used and exactly how and why?

>This is what Mobile IPv6 has been missing. PANA is the right piece

I think Mobile IPv6 should indeed get some way to do authentication with 
EAP. Whether PANA or a Mobile IPv6-specific encapsulation of EAP is 
required or a best fit is still open for debate :-)

Jacques.

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Feb 2002 17:33:54 -0500 (EST)

> Isn't this already what happens after PPP auth?!?

Yes, but PPP has fine-grained authorization.  Authentication is
*defined* to come first (before network layer access is granted), and
the security services that most NAS manufacturers use have features to
allow selection of which network layers to allow.

Note that the authorization is done over PPP.  This means that there's
no IP-centric assumption as with PANA.  For PPP, you could easily
authenticate for use with just OSI without ever touching IP.  For
PANA, that doesn't seem to be one of the options, as IP access is
assumed from the start.

> it uses this specific IP address as the source....

Hmm.

> > there's as yet no signaling between the PAA and the NAS.

"Ew."  In any event, I think that either of those solutions would take
a fair amount of effort to define into the architecture presented.  A
draft describing this would be interesting, though.

> what i'm talking about. (access control vs. ownership issues?)

Yes; way different.  If the Mobile IP group doesn't want to define AAA
mechanisms, should PANA necessarily be doing their work for them?

> > authorization issues that need to be dealt with as a part of that

Really?  No choice of QoS mappings for the tunnels?  No selection of
different reliability features?

> can deploy Mobile IPv6 with PANA. All L3 solution.

That's certainly one way to go about it.  Unfortunately, it loses the
linkage between the access mechanism and the authorization.

> of world comes :) will have their own.... But doesn't this itself say

It says that L2s are more similar than they are different, and that
defining a new L2 is hard work that should not be undertaken just for
the fun of it.

In other words, it's quite likely the case that more than a few of
those "new" L2s are really just rewarmed versions of old L2s and
should not be made gratuitously different.

> We are trying to break this trend: every L2 has its own EAP carrier. But you

Yes, I do.  I like it because it helps solve a lot of the complex
authorization issues and because it's a deployed and workable solution
in common use today.

> > consensus, especially among those not criticizing PANA.

Doesn't that say something?

---

From: Jacques Caron <[email-masked]>
Date: Fri, 08 Feb 2002 23:36:47 +0100

>Isn't this already what happens after PPP auth?!?

Authentication is just a preliminary to authorization. Once the client is 
authenticated, the NAS can ask the home server what protocols it should allow.

>Bluetooth, as Jacques was suggesting.

Uhuh. I don't think I ever suggested Bluetooth needed PANA. I said 
Bluetooth needs an EAP encapsulation. And last I heard, that's in progress 
(btw, note that it also allows non-IP connectivity over Bluetooth to be 
authenticated, authorized and accounted, like serial emulation for instance).

>And maybe others that I don't know.

See my other post on why I feel it is better that way. And that was without 
even mentioning the security issues related to PANA being over IP.

>it will fix "basic requirements for all L2s" initially,

As an interim solution: OK.

>  and gradually

See my other post.

Jacques.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 8 Feb 2002 17:53:20 -0500

James,

> authorization mechanisms break.  Why duplicate the effort?

What do you mean by "existing L2 authorization mechanisms"?

> among various access technologies.

That depends on the usage scenarios.  

> the assumptions that create the need for PANA, and that PANA can't fix

If a provider wants to support intra-domain inter-technology handoff,
it would be natural to make L2 authentication lightweight as much as
possible, regardless of whether differing authentication methods 
between different link layers or not.  As I'm repeatedly mentioning, 
the usage scenario would be different from what you are thinking.

> place.  What bits of context would you like to transfer?

I mean context for local security association.  We assume that local
re-authentication occurs witout contacting to an AAA server at all.

> all.  In fact, PANA appears to be intentionally divorced from address

No, I'm not asserting that.

> Is redoing authentication to get new keys a problem?

No other context here.  The same problem would occur if PAA changes
witout using some context transfer protocol.  This is a good point.
However, unlike the traditional NAS, the location of PAA is flexible
so that one can design a network PAA does not change.

> back to normal authentication.

As I mentioned above, we assume that local re-authentication occurs
without contacting to an AAA server at all.  Of course, you can try to
implement your scheme and propose it somewhere, but I believe the PANA
WG is not the right place to propose that.

> links in the same way.  Why is that a problem?

Once again, we assume that local re-authentication occurs
witout contacting to an AAA server at all.  

> > everything-in-L2 approach we really want to avoid.

As I replied to someone else, I already answered this kind of question 
within other thead.  

> Where is the "everything-in-L2" assumption?

I mean "authentication for network access is always performed at only
L2".

Huh?  In fact I remember you made some comments related to this:

   > The allow-unknown-users-to-connect-with-minimal-privileges scenario is
   > one that I think will be compelling.  It allows the provider to (for
   > example) present the user with web-based form to sign up for
   > additional levels of access.
   > 
   > The ancient example of a working interface like this was the old
   > "library" user available at some universities.  This was a special
   > user name that didn't prompt for a password, but allowed access to
   > just the local research library.  Thus, remote users could dial in and
   > get 'guest'-level access without having to register.

Or is this a different thing?  Then please explain.

> is a solution out in search of a good problem.

We can continue the discussion.

Yoshihiro Ohba

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Feb 2002 18:15:51 -0500 (EST)

> What do you mean by "existing L2 authorization mechanisms"?

For example, on a NAS using PPP and RADIUS for authentication, the
base protocol allows for authorization of at least:

	- Authorized IP address (Framed-IP-Address)
	- Link-layer data compression (Framed-Compression)
	- Session-Timeout
	- Idle-Timeout
	- Number of concurrent sessions for multilink (Port-Limit)

See RFC 2865.  There are, of course, *lots* of proprietary extensions
to this and even proprietary authorization protocols as well.  All of
them depend on L2 authentication first.  If you null out L2
authentication, then all of this Proposed-Standard infrastructure
falls away, to be replaced by nothing.

> That depends on the usage scenarios.  

No.  It depends on the current text in the requirements draft.

> the usage scenario would be different from what you are thinking.

If the core problem is the "weight" of the reauthentication
procedures, then why not attack that problem instead?  That appears to
be a better problem to solve in that it's more broadly applicable.

For instance, a good solution here might make the "short hold" crowd
happy enough that they don't want to have special PPP procedures for
use with ISDN.  That would be a very nice side effect.

> re-authentication occurs witout contacting to an AAA server at all.

I think that all you've done is rename the problem.

In the previous view of the world, the end-node sent L2-specific
authentication requests to the NAS/AP and the NAS/AP sent AAA packets
to the AAA server and did the authentication.  Perhaps the whole thing
happens twice when crossing from one link technology to another, as
you point out.

In the PANA view of the world, the end node sends packets *through*
the NAS/AP that end up landing on a single PAA that can do the
reauthentication.  However, now that you've got packets going from the
NAS/AP out to some other node to do the actual authentication, this is
really just the same situation as before: it just replaces "PANA" for
"AAA" and "PAA" for "AAA server."  The number of messages on the
wires, the implications for congestion and delay, and the functional
roles are exactly identical.

If it's really the case that reauthentication is an important problem
to solve (I have not seen the data to suggest that this is the case),
then why not attack that problem in particular?

> so that one can design a network PAA does not change.

The location of the AAA server is flexible in exactly the same way.
This is just a name change.

> without contacting to an AAA server at all.

Actually, that's not the case.  You contact the PAA, which, in the
PANA world, serves effectively as the same extra-hop-away server as a
AAA server would in the non-PANA world.  Is there some reason to
believe that a PAA server is going to be significantly faster or
better than a AAA server?  I don't follow the logic that suggests it
would be.

>  Of course, you can try to

Clearly not.

> Or is this a different thing?  Then please explain.

I don't see how that is something that turns out to be impossible at
the first-hop L2 device but suddenly becomes possible at some interior
L3 node.

Given that people have done exactly this with NASes in the past, I
think that it's rather hard to argue that this can't be done.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 8 Feb 2002 19:30:16 -0500

> falls away, to be replaced by nothing.

But the authorization can be done with null L2 authentication. 
And PPP does not mandate the use of RADIOUS.

> No.  It depends on the current text in the requirements draft.

OK.  PANA requirements I-D and/or PANA interactions with PPP and
802.1X I-D may need to address something to realize intra-domain
inter-technology handoff.

> be a better problem to solve in that it's more broadly applicable.

OK.  I'll try to add some text for that.

> roles are exactly identical.

Interesting point.  But it would complicate AAA protocols.  In fact, I
remember an approach similar to your proposal is considered for Mobile
IP, but now it's gone.

> then why not attack that problem in particular?

I'll try to add some text for generic issue of that, and 
Franck could provide some text for Mobile IPv6.

[...]

> think that it's rather hard to argue that this can't be done.

I have never said this *can't* be done with NASes in the past.  I just
consistently keep mentioning that "anything is possbile if the
solution is based on layer violation".  We should avoid layer
violation as much as possible in order to have much cleaner solution.
I anticipate we will get into circulating discussion if 
we cannot agree on this point.

Thanks,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 8 Feb 2002 16:39:35 -0800

> times, given the number of SHOULDs relating to that bit :-/

I won't respond to this, as this would side track us into discussing if
RFC2002
works or not :)

> to compensate for the lack of authentication on the local link (RFC2002 is

Yes, and this is the beauty of L3 protocols :) They don't assume every
feature
is available on every link layer ..... What you call "hack to compensate .."
is
lower-layer independence of IP.

> Any hints of contexts where this is used and exactly how and why?

Others might contribute here.. I have already given my explanation: using
FA as an attended (like PAA) for network access.

> required or a best fit is still open for debate :-)

I hope not :) A generic solution like PANA that also serves the needs of
Mobile IPv6
should be the clear winner!

alper

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 8 Feb 2002 16:53:00 -0800

Jim,

> allow selection of which network layers to allow.

Initial PANA cannot do that, but PANA+ can. (I already explained
the reason for this phased approach).

> PANA, that doesn't seem to be one of the options, as IP access is

"Ability to send limited IP packets (only PANA requests to PAA)" is allowed,
not "IP access" (which can easily mean more :).

> mechanisms, should PANA necessarily be doing their work for them?

We are not doing this for them, but what we do is useful to them as well....

> different reliability features?

These are none of the business of "mobility management"... These are network
access related. Operators want to control who uses their network. Even if a
mobile node configures a co-located care-of address and not use a foreign
agent
like functionality for Mobile IPv6, they still want to have what they could
do with
Mobile IPv4 foreign agents with R bit.

> linkage between the access mechanism and the authorization.

not sure if i can follow what is wrong with this use of PANA....

> defining a new L2 is hard work that should not be undertaken just for

Agreed....

> should not be made gratuitously different.

I cannot  guess this....

> Doesn't that say something?

It's too small of participation in the discussions and too soon (is the req.
draft read carefully
by all?) to talk about rough consensus...

I'm tuning out...have a nice weekend all!

alper

---

From: James Carlson <[email-masked]>
Date: Sat, 9 Feb 2002 01:04:49 -0500 (EST)

> But the authorization can be done with null L2 authentication. 

Really?  How is that the case?  If you don't know who the client is,
how do you know what authorization to grant?

> And PPP does not mandate the use of RADIOUS.

Of course.  But it certainly permits it, and this is often the way
it's used in NASes.  This is the point: there are very many access
providers who rely on L2 (i.e., PPP) authentication to drive L2
authorizations.

> inter-technology handoff.

I think PANA still cannot enforce the type of authentication done
without charter changes.  PANA is just a carrier.

> remember an approach similar to your proposal is considered for Mobile

Huh?  Your comment doesn't appear to be related to my words above.

What I was saying was that instead of having the NAS/AP send AAA
packets to the AAA server to authenticate the end node, PANA has the
NAS/AP relay the end node's PANA packets to the PAA to authenticate
the end node.  There's no net benefit from PANA: it's changed the
names of the systems involved in the exchange, and changed the names
of the packets, but there's still a AAA-like round trip involved, and
the same amount of signaling.

Again, why would we expect the PAA to be faster than a AAA server?

> solution is based on layer violation".

Why do you insist that this is a layer violation?  Where exactly is
the violation?

>  We should avoid layer

If I can't understand (or nobody will explain) where the layering
violation occurs when L2 carries authentication information, then
you're right; we're just going to keep repeating.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 9 Feb 2002 03:36:21 -0500

> how do you know what authorization to grant?

For example, granting unconditional packet forwarding to any client.
It is definitely one type of authorization.

> without charter changes.  PANA is just a carrier.

OK.  But I still think the WG can recommend something on L2.

> Again, why would we expect the PAA to be faster than a AAA server?

In your proposal, protocol translation (PPP/802.1X <-->
RADIUS/Diameter) is inevitable at NAS/AP, that requires more
processing delay than PANA model.  So PANA model is faster than your
model.  But that would not be the actual problem.  The actual problem
I mentioned above is that your proposal would complicate AAA protocols
since an intermediate AAA server in the visiting domain must have a
state to support local re-authentication.  More importantly, I don't
think your model can support local re-authentication when initial
authentication is performed also locally at NAS/AP without contacting
to the AAA infrastructures at all.

> Why do you insist that this is a layer violation?  Where exactly is

I once explained that in a different thread:

   "It seems to me that this is a layer violation if the AP would need
   to either control with which IP subnet (or VLAN) the user's device
   is associated, or look through the payload of MAC frames carrying
   user data.  It seems to me that using PANA for this case is much
   simpler than the above scheme."

This would be one type of layer violation.  Another type of layer
violation would be the case in which higher layer signaling occurs
between NASes that perform L2 authentication in order to transfer
security association context.  There may be other.  That is a rough
sketch, and more formulation may be necessary.

> you're right; we're just going to keep repeating.

Have a nice weekend,
Yoshihiro Ohba

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 9 Feb 2002 19:30:30 -0800 (PST)

Hello,

I'm not finished with the thread, but this is what I
captured. Feel free to provide correction/additions

List of Issues that are open/need clarification
===============================================

1 - Authorization

Should it be in-scope? To what extent? 
In a real network can we have a pure authentication
protocol?

2 - Should PANA duplicate functionalities already
present in other protocols?

3 - Notion of is actually being authenticated: User ID
vs Link Layer ID 

4 - DI as an access independent parameter. 

Text to be added
=================

1 - Non multi-access aspect of PPP - James Carlson 

PPP provides an inherently point-to-point interface. 
This is by
design.  If you have a multiaccess subnetwork (e.g.,
Ethernet), then
you're certainly not using a point-to-point model.  In
particular, 
you have arbitrary peer-to-peer relationships on that
network (which, to
emulate with PPP, would require either a full mesh of
point-to-point
links, or the use of a designated router) and you
likely have the
options of broadcasting and multicasting (depending on
the exact
technology used).

2 - PPP Framing vs Encapsulation Terminology - James
Carlson 

3 - DDoS - James Carlson.

I don't think that's sufficient.  Because PANA is a
carrier for
authentication protocols, and authentication
necessarily involves
computational complexity far in excess of that
required for TCP, it's
particularly vulnerable to attack.  I also think that
at least part of
the issue falls on the design of the authentication
protocols carried
by PANA and is thus out of scope.

	- How are PAAs protected against attack?  The logical
place
          that PANA can affect this (without becoming
too intimate
          with the authentication protocols
themselves) is in the
          discovery stage.  Thus, discovery likely
needs to be
          throttled by the PAA itself.  Some
recommendations are might
          be necessary there, but I suspect that the
general problem
          is intractable.  (If you start slowing down
discovery, how
          do you distinguish among requests from
unknown but valid
          clients and requests from unknown and
invalid attackers?)

	- How are PaCs protected against attack?  This
appears to be a
          lot harder.  Because the relationship isn't
quite symmetric,
          a PAA isn't affected by the presence of a
rogue PAA on the
          same network, but the PaCs certainly are. 
PaCs can be
          attacked by compromised or bug-ridden PAAs.

	- Does any of this actually matter when a multiaccess
network
          itself can be trivially (or inadvertently) attacked?

---

From: James Carlson <[email-masked]>
Date: Mon, 11 Feb 2002 09:14:02 -0500 (EST)

> It is definitely one type of authorization.

Perhaps.  It does introduce some new complications, though.  For one
thing, it means that the end node can stay connected for an arbitrary
period of time without authenticating.  This is likely a useful
feature for attackers; especially those intending to spoof the PAA.
Unless there's some PAA to AP authorization magic, this may also mean
that the the provider's L2 can be used as a free "party line" service.

And, as described before, it means that IP address assignment very
likely occurs without benefit of authentication.  I find that quite
troubling.

> processing delay than PANA model.

There's already "protocol translation" going on -- link layer data
from one medium to the other must be translated.  Part of the
assumption here seems to be that the PAA-based architecture inherently
scales better than the traditional AAA-based architecture, but what
seems to be missing is an actual analysis of the costs.

>  So PANA model is faster than your
> state to support local re-authentication.

I don't see how this is necessarily true.  If the NAS or PAA has the
data necessary to do local re-authentication, then that data must have
passed through any intermediate AAA server.  In other words, if you
have this working (where 'client' is some machine doing an access
determination; a NAS or PAA):

	1.  client <---> AAA server

and this is also known to work:

	2.  client <---> AAA intermediary <---> AAA server

Then you can reduce that to:

		client'
	+-------------------------------+
	| client <---> AAA intermediary |<---> AAA server
	+-------------------------------+

Where client' is known to have all the right data to do
reauthentication by (1).  If the AAA protocol in use works at all for
local re-authentication and intermediaries, then it necessarily allows
re-authentication at the intermediary without changes to the protocol.

(Note that I didn't actually assume *any* intermediate AAA servers.
Not that it actually matters one way or the other.)

>  More importantly, I don't

Huh?  Authentication mechanisms that support local re-authentication
don't themselves require AAA.

Are you assuming the use of "local" re-authentication and roaming
between NASes/APs?  If so, then I'd say that exactly the same issue
affects PANA -- if there's more than one PAA.

>    is associated,

Are you saying that you consider PPP to be improperly designed because
it allows IP endpoint addresses to be negotiated?  If so, then I think
that's a rather extreme use of the concept of a "layering violation."

>    or look through the payload of MAC frames carrying

Not true!  VLAN assignment has to occur at the L2 node; there's really
no choice at all.  PANA complicates the matter greatly by making that
assignment *separate* from the actual authentication.

There are two cases here, regardless of the use of PANA:

	1. the L2 access node requires the end node to do its own
           802.1q VLAN tagging, or

	2. the L2 access node does the 802.1q VLAN tagging on behalf
           of the end node.

In case (1), the access node will need filters so that the end node
can be restricted to the assigned VLAN.  In case (2), the access node
will need the VLAN ID so that it can do the proper tagging.

In both cases, exactly the same authorization data are required: the
end node's assigned VLAN ID.  This is needed at the L2 access node.

Note that both cases above are excellent arguments against PANA.
Before the authentication occurs, it's impossible to tell to which
VLAN the end node has been assigned.  But, if you don't know the VLAN
ID, then you can't bridge frames, and the end node can't communicate
with the PAA.  (In case 1, the end node does not know which VLAN tag
to use.  In case 2, the access node doesn't know it.  In both cases,
frames can't get past the access node.)

Note that under 802.1x, case (2) works perfectly: the end node
authenticates to the access point, which can then retrieve VLAN
authorization and set up the proper tagging.

Could someone suggest a scenario in which this configuration works for
PANA?

> sketch, and more formulation may be necessary.

Assuming context transfer is at all necessary (and that, somehow, a
deployment with more than one PAA doesn't require such transfers), how
is a communication among peers that all speak the same AAA protocol a
"layering violation?"

I don't think this is a useful concept.  With strict enough terms,
every real protocol is a "layering violation" -- the PANA ID bits, ARP
data, IPv6 neighbor discovery, and many others.  I don't think that
argument results in any additional light on the problem.

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 11 Feb 2002 11:20:24 -0800

Hi Reinaldo,

Thanks for compiling this list. I had my own list in raw format (marked
e-mails)
but not a digest like yours.

Comments below.

> List of Issues that are open/need clarification

Requirements draft has a position on this. Regarding more detailed
authorization, my personal take is "not now, can be done later".

> present in other protocols?

I think this is not for the requirements draft (yet).. This is a high-level
discussion that has been going on regarding the charter and the scope
of this work. We also have some charter items to address this:
"PANA interactions with PPP and 802.1X"

> 3 - Notion of is actually being authenticated: User ID

I think requirements draft is clear. Some discussions happened
on this, but that was more like some disagreements "between posters"
rather than "between posters and the draft". So, if any issues on this
within the requirements draft, please somebody bring it up.

> 4 - DI as an access independent parameter.

Thanks.

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 11 Feb 2002 15:24:08 -0500

James,

> likely occurs without benefit of authentication.  I find that quite

But that's actually happening in network access services at air ports,
hotel lobbies, coffee shops.  How do you explain this?  Do you want to
shut down those services?  I believe you cannot.

> from one medium to the other must be translated.  

I would say "additional protocol translation" is required in your
scheme as well as media translation.

> Part of the

In terms of basic functionality, perhaps you are right.  But in your
model, "client" part is separated in different nodes, AP and NAS.
This means that AAA signaling messages originated from the AP and the
NAS may not pass through the same AAA intermediary, which makes your
scheme difficult to work in general environment.  On the contrary, the
PANA model, there is no difficulty of this kind as long as "client"
part is the same PAA (for the case where there are multiple PAAs, see
below).

> don't themselves require AAA.

But your "local re-authentication" scheme actually requires AAA protocol 
between the intemediate AAA server and client (NAS or AP).
That's what I mentioned.

> affects PANA -- if there's more than one PAA.

If there's more than one PAA (although this case is out of the scope
of PANA), transfer of local security association context would be
necessary (see my second last comments below for more explanation on
this).  But it could be achieved without layering violation that I
mentioned since context transfer happens in the same layer (i.e., L3)
as authentication.  Anyway, I can say that your scheme does not work
better than the PANA model.

> that's a rather extreme use of the concept of a "layering violation."

PPP is a very special case in which network layer configuration is
built-in, and thus I don't say PPP itself is doing layering violation.

> Note that both cases above are excellent arguments against PANA.

Not at all.  Now I have to let you come back from the circulating
discussion.  Mandating the use of VLAN for realizing a PANA usage
scenario is one of what we want to avoid.  L2 protocols cannot enforce
the use of VLAN to the IETF.  

> frames can't get past the access node.)

I don't understand at all why IETF protocols should take care of VLAN
configuration.  

> is a communication among peers that all speak the same AAA protocol a

As long as it carries L2 security association context among different
L2 technologies it is a "layering violation", since it is not
guaranteed that the same context is used among different L2
technologies and thus interoperability problem could easily occur.  On
the contrary, in the PANA model, the LSA context for PANA is
independent of L2, and thus it is very easy to avoid such kind of
interoperability problem.

> argument results in any additional light on the problem.

I'm not talking about layering violation in general.  I didn't say
that the cases in which higher layer protocols carry lower layer
information are "layering violation".  They are very important
elements and are mandatory for routing IP datagrams.  The "layering
violation" I mentioned is the one that are not mandatory for routing
IP datagrams.

Yoshihiro Ohba

---

From: James Carlson <[email-masked]>
Date: Mon, 11 Feb 2002 16:03:09 -0500 (EST)

> shut down those services?  I believe you cannot.

No, of course not.  PANA doesn't affect this: if those services are
unauthenticated today they should stay the same.  If they're using
HTTP-snarfing tricks, I don't see how PANA help.

The problem that I have here is that PANA (possibly depending on the
beholder; requirements aren't clear here at all) defines the
authentication to occur *after* the IP address assignment is done.
That's too late.  If people care about authenticated access, then I
think that authorizations (such as IP addresses) must *follow*
authentication, not precede it.

> scheme as well as media translation.

Not by much -- EAP is intentionally designed so that the NAS doesn't
do very much.  It takes off the link-layer wrapper and forwards the
guts to the AAA server.

> scheme difficult to work in general environment.

That's exactly the same problem with PANA: the PAA reached via one
access technology might not be the same as the PAA reached through
another access technology.  If the provider wants it to work, he has
to configure it such that it uses the 'right' services.

>  On the contrary, the

How or why is it the case that getting several APs and NASes to use
the same backend AAA server is "difficult" and not "general," but that
requiring the same PAA server to handle requests from multiple APs and
NASes isn't hard and doesn't result in loss of generality?

What am I missing?  It looks like exactly the same problem to me.

> between the intemediate AAA server and client (NAS or AP).

Or requires that NAS and AP are identically the same.  So, the case
that we're worried about is the case where "local" authentication is
done by the PAA?  I guess I don't see the difference between that case
and the case where the NAS and AP use a AAA protocol to communicate
with precisely *ONE* AAA server (no intermediary; just a single AAA
server) doing self-contained authentication.  The AAA server thus
becomes equivalent to the PAA.

> as authentication.

I still don't see a layering violation of any sort here.  The
communications that occur are purely L7 -- an application protocol
that happens to talk about authentication and authorization.  Where is
the violation?

>  Anyway, I can say that your scheme does not work

It's better in that it doesn't involve new protocols.

> built-in, and thus I don't say PPP itself is doing layering violation.

OK, then, is an AP that uses an authentication and authorization
protocol (such as RADIUS) to determine VLAN membership depending on
"layering violations?"

I simply do not understand this usage of the term "layering
violation."  I wouldn't be pushing so hard on it, since it might just
be a wording issue, except that it seems to be central to the case for
doing PANA over IP.

> the use of VLAN to the IETF.  

I don't understand that response at all.

Suppose I'm a provider.  Suppose I *WANT* to use multiple VLANs -- for
whatever reason.  Suppose I *WANT* to authenticate users and assign
them to particular VLANs based on identity.

I don't think that's an outrageous request.  How do I do it?  It seems
to me that PANA simply cannot do it at all.

I'm certainly not suggesting that we *FORCE* anyone to use VLANs.  I'm
not wild about them myself.  But what do we do *when* they're used?

> I don't understand at all why IETF protocols should take care of VLAN

I think that the owner of the box cares more about service deployment
than about who "owns" what protocols.

In any event, 802.1x can use EAP and RADIUS.  RADIUS can do fine-
grained authorization.  Why would it be unreasonable to suppose that
granting VLAN access could be controlled by a RADIUS server?  Merely
because 802.1q is outside the IETF?  Well, that's true for a lot of
the data that AAA protocols can carry.

Step outside of the 802 world for a moment.  Suppose that the
authorization is done for ISDN calls based on IEs presented by the
switch.  If the switch says that the call is local, then (perhaps) we
turn off link-layer encryption for performance reasons and use a
simple authentication scheme.  If it's non-local, then we only allow
certain users in, and for those we enable encryption and use a token
card based authentication scheme.

Would that be unreasonable?  How would PANA deal with such a
situation?

> interoperability problem.

The security association is between the communicating nodes.  If both
are speaking EAP, then I fail to see what the "interoperability
problem" might be when the transport is changed.  If they're not both
speaking EAP (or at least speaking exactly the same authentication
method in both cases), then PANA will also fall apart, because it
assumes the same method is used on multiple media.

> violation" I mentioned is the one that are not mandatory for routing

"Mandatory for routing IP datagrams" is the requirement?

If your access to the network is controlled by an L2 device that does
authentication, then I'd certainly say this function is mandatory for
routing IP datagrams on that network.  If it's merely the case that
when things are "needed" then they're not "layering violations," then
I think we're all set.  L2 authentication is thus not a layering
violation because it's needed for network access.

Besides, aren't PANA ID bits a layering violation?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 11 Feb 2002 18:50:52 -0500

> HTTP-snarfing tricks, I don't see how PANA help.

No problem, PANA will replace the tricks :)

> authentication, not precede it.

No, it depends on the scenario, as I'm repeatedly mentioning.

> to configure it such that it uses the 'right' services.

But the location PAA is flexible enough to be shared among different
L2 technologies as much as possible, that is the difference from your
model.

> What am I missing?  It looks like exactly the same problem to me.

In PANA model, AAA protocol is not mandatory for both initial
authentication and local re-authenticaion.  In other words, the PANA
model is self-contained in that sense and what you are missing, I
guess.

> becomes equivalent to the PAA.

As mentioned above, the degree of "self-containing" is different.
The PANA model is highly self-contained than your model.

> that happens to talk about authentication and authorization.  Where is

If direct communication between AP and NAS for transferring local
security association context is required in your model in order to
avoid the use of AAA protocol interaction for local re-authentication
that would be "layering violation" that I mentioned.  But this 
might not be a big issue (see below).

> protocol (such as RADIUS) to determine VLAN membership depending on

It seems to me, yes.  But as you commented below that would be a simply 
wording issue.  

> be a wording issue, except that it seems to be central to the case for

OK.

> not wild about them myself.  But what do we do *when* they're used?

I think that the above scenario that a user can select one of multiple
VLANs is a different scenario from what PANA is trying to solve.  You
can use L2 authentication to achieve that.  But that cannot be a
reason for denying PANA, because scenario is different.

> than about who "owns" what protocols.

The owner of the box cares more about service deployment and the cost
of the box (the former might include latter).  If the cost of the box
depends on the set of protocols used for realizing the service, it is
valid for having multiple sets of protocols for realizing the same
service and letting the provider choose whatever set of protocols they
want to use.

It might be more understandable to discuss PANA in terms of deployment
cost than layering violation.

[...]

Thanks,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 11 Feb 2002 19:26:32 -0800

Jim,

> authentication to occur *after* the IP address assignment is done.

The draft doesn't say that the authentication must occur after
IP address assignment. IP address assignment can happen
before or after PANA. PANA has no strict order.
If it makes sense one way or the other, PANA works
either way.

> authentication, not precede it.

PANA can do that too. Requirements don't conflict with this.

alper

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Feb 2002 23:39:35 +0100 (CET)

Jim,

I think it's not necessarily that they MIP group didn't want to define things
but that they were convinced that AAA mechanisms isn't fundamental to 
mobile IP but an issue for IP access whether or not mobile IP is used.

Of course, Mobile IPv4 predates this just like Mobile IPv4 predates
using DHCP for address allocation, which is part of the reason
MIPv4 and AAA are joined at the hip.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 12 Feb 2002 23:39:59 +0100 (CET)

> can deploy Mobile IPv6 with PANA. All L3 solution.

While authentication is needed in this context, it isn't obvious to 
me that is it required to have the same attributes as the Mobile IPv4
approach.
In particular, it isn't obvious that the authentication and access control
function needs to treat mobile IPv6 nodes differently than other IPv6 nodes -
they could potentially just authorize IP access and whether the device
uses MIPv6 is up to the device.

I don't know if you meant to imply "same effect" to this level of detail or
not.

   Erik

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 12 Feb 2002 15:53:50 -0800

Erik,

> uses MIPv6 is up to the device.

I agree. I wasn't suggesting that PANA should do anything specific to
Mobile IPv6. The client can get IP connectivity first, and then can choose
to use it with Mobile IPv6.

> I don't know if you meant to imply "same effect" to this level of detail
or

I meant it at a higher level. Just to have a "check point" in the visited
networks...

alper

---

From: James Carlson <[email-masked]>
Date: Wed, 13 Feb 2002 08:37:47 -0500 (EST)

> mobile IP but an issue for IP access whether or not mobile IP is used.

I'm not sure that's a view that's without contention, and RFC 2977
would appear to differ.

I agree that AAA is fundamental to IP access.  I don't agree that this
necessarily means that the right thing to do is to divorce it from the
low-level access mechanisms.  The loss of access-specific information
and control is a serious problem.  Relying on the end node to supply
access-specific information would be even worse.

> MIPv4 and AAA are joined at the hip.

Would you then argue that removing authentication from PPP and from
Ethernet 802.1x is the right path for the future?  I see Mobile IP as
been essentially equivalent to these other L2 protocols in terms of
its security implications: it inserts an IP interface into a network.

The special case for Mobile IPv6 appears to occur only because
authentication can be punted off to IPsec.  Otherwise, Mobile IPv6
does include an authentication mechanism for Binding Update messages.
That mechanism, though, doesn't appear to be designed to link into
existing AAA services, which appears to mean that each Home Agent must
be separately configured with keys and any necessary authorizations,
and that accounting has to take place via some Mobile-IP-specific
mechanism.  Perhaps I'm unclear on the concept, but I don't see how
that's a good situation.

Consider what happens with an 'inside' attack -- where the attacker
has a valid security association.  It certainly seems to me that
Mobile IPv6 using only IPsec for security allows a remote node to
contact the HA and then redirect traffic for *any* node within the
home network.  I haven't spent a lot of time studying Mobile IP (and I
know that you have), but that would seem to make it harder to limit
the scope of damage that's possible ...

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Feb 2002 15:34:12 +0100 (CET)

> I'm not sure that's a view that's without contention, and RFC 2977

I think the statement I responded to was only about MIPv6
and not MIPv4.

> access-specific information would be even worse.

Are you viewing mobile IP as a low-level access mechanism?
I view MIP as an overlay on top of IP.

> Ethernet 802.1x is the right path for the future? 

No, I don't argue that PPP and 802.1x should drop authentication.
What makes you think that?
I think L2's are very different than overlays like mobile IP.
In the mobile IP case it makes sense to
1) authenticate locally (to the "link" - whatever is the best way to describe 
   this) to get IP connectivity
2) authenticate to the home agent to get the mobile IP part going

My point is that I think we loose something if we make 1 and 2 be too closely
tied together. For instance, for 1) I might want to authenticate as
	[email-masked]
and for 2) I might want to authenticate as
	[email-masked] (or [email-masked] if the home
	agent is in my house)

Of course, there might be cases when there isn't a need to authenticate 
using an NAI in step2 but instead rely on some shared secret between the 
mobile device and the home agent.

The model in MIPv4 / RFC 2977 at a minimum makes the above distinction
rather muddled.

> I see Mobile IP as

I think that view of nested links and interfaces is consistent with
what I wrote above.
The ability to separately authenticate at the physical link and
at the establishment of the overlay interface/link provides this.

Of course, one can debate whether there is a need to do EAP authentication
for the MIP overlay. Both MIPv4 and MIPv6 take the tack of just relying
on a shared secrete for the authentication of the MIP overlay.

> mechanism.  Perhaps I'm unclear on the concept, but I don't see how

You have some MIPv6 catching up to do I see :-)
But in general both MIPv4 (including the AAA extensions) and MIPv6 have
the model of a shared secret.
The only difference between the AAA extensions to MIPv4 is that the
secret is shared between the MN and the AAAh, but you still can't use
EAP to do the authentication in any of the MIP cases.

Do you think being able to use EAP for MIPv* as the right way?

The natural model for this would seem to be

	    tunnel/overlay
	MN ================ HA ----- AAA

i.e. the HA has the same role as the NAS but for establishing an overlay
interface instead of a PPP link.

FWIW The above is a very different picture than RFC 2977.

> the scope of damage that's possible ...

The work that has been and is currently ongoing is to do a reasonable
job of determining the way to establish the authority to do binding updates
for a given home address.
The current thing being persued for correspondent nodes handling binding
updates is to rely on what is called return routability i.e. the property
that the routing system is trusted enough to deliver IP packets to
their destination, and verifying this using a 3-way exchange.
For MN to HA authorization it seems rather straigh-forward to
associate an IPsec security association (using manual keys) with
the policy that binding updates received using that SA can update binding
for the specific home address.

How's that for an attempted short summary?

   Erik

---

From: James Carlson <[email-masked]>
Date: Wed, 13 Feb 2002 10:10:33 -0500 (EST)

> I view MIP as an overlay on top of IP.

Yes, I'm viewing it as a MN-HA tunnel, which is morally equivalent to
an IP link.  It's certainly true that the CN behavior in Mobile IPv6
muddies the water a bit, but I think that's essentially just an
optimization.

> What makes you think that?

Because those are other ways to create IP links.

> 2) authenticate to the home agent to get the mobile IP part going

I see this as a multi-level instance of the same thing.  In other
words, there's a local link, and there's a link-like tunnel running
over that.  The authentication has to be performed between the nodes
forming the link: and these are different at the two levels.

(At least in principle, one could imagine having more than two levels:
a local link, a Mobile IP tunnel to some home network, and another
tunnel to some interior network running over that.)

> 	[email-masked] (or [email-masked] if the home

Agreed, but for completely different reasons.

> mobile device and the home agent.

I'd say that's a special case of the usual access architecture: an
access device can use a AAA mechanism, or use local authentication
methods.  Stored secrets on the HA and MN constitute a local
authentication method.  That works fine as long as the deployment is
small and simple.  It gets harder to manage if the deployment is
complex or involves different kinds of authentication in different
contexts.

> The model in MIPv4 / RFC 2977 at a minimum makes the above distinction

I agree that the involvement of the FA for IPv4 is odd and makes the
distinction difficult.  There are indeed two parts: access to the
foreign network is separate from access to the HA.

> at the establishment of the overlay interface/link provides this.

Right.  We're in violent agreement.

> on a shared secrete for the authentication of the MIP overlay.

Right.  I'm arguing that I'm not sure that local authentication and
authorization by the HA is good enough.

> You have some MIPv6 catching up to do I see :-)

Yep.  ;-}

> Do you think being able to use EAP for MIPv* as the right way?

That's actually a separate question.  One question is whether the HA
should be able to use a AAA service at all to authenticate the MN.
The other is what the authentication protocol between the MN and HA
should be.

EAP might be helpful in that it addresses one of the concerns of PANA:
being able to use the same authentication methods for different types
of access mechanisms.  In other words, why should I use one method
when I dial up to the corporate site, another when I'm using 802.11 in
a corporate conference room, and still another when I authenticate my
Mobile IP session on the road?

So, my answer would be a very cautious "yes."

> interface instead of a PPP link.

Yes.  I strongly agree, and that was my original point.  In as much as
the HA behaves like a NAS, it should probably behave like a NAS --
which involves authentication, authorization, and accounting.

> FWIW The above is a very different picture than RFC 2977.

Yes, I know.

> How's that for an attempted short summary?

OK.  So we're back to authorizations (home address assignments) that
are administered locally on the HA, right?  In other words, the HA
needs some sort of table to relate the IPsec SA to the MN's purported
home address.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 12:12:11 +0100 (CET)

> muddies the water a bit, but I think that's essentially just an

Agreed. But the optimization means that some packets are not seen by the HA
i.e. the HA can't perform accounting and fine granularity access control
the way a NAS can.

> complex or involves different kinds of authentication in different

Hmm - it would be interesting to look at what the model of pools of
modems and NASes plus AAA backend would look like for MIP.

But there might be some different underlying assumptions in MIP in that
the purpose of MIP is to provide a reasonably stable IP address while the MN
moves. Thus you don't want to change the association between the MN and its
HA too often if that implies that the MN gets a different Home Address.
I wonder if that assumption should effect the model or whether it
conceptually is just low-level issue relating to how often the
tunnels are being torn down and recreated.

> which involves authentication, authorization, and accounting.

See above on fine grain authorization and accounting not being
possible with MIPv6 route optimization.
So I agree that the model should be the same, but the details might differ
a fair amount.

> needs some sort of table to relate the IPsec SA to the MN's purported

Yes, the MIPV6 HA needs a table that conceptually contains 
<Home Address, shared secret> pairs in MIPv6. It hasn't been discussed
whether this should be extensible to do other forms of authentication with
AAA backend.

In MIPv4 with AAA support the AAAh server conceptually contains a table with
<NAI, shared secret, home address> and the authentication does not
support different methods akin to EAP.

  Erik

---

From: James Carlson <[email-masked]>
Date: Thu, 14 Feb 2002 08:16:38 -0500 (EST)

> i.e. the HA can't perform accounting and fine granularity access control

It does place limitations on those functions (filters are going to
have interesting behaviors), but some of the functions that I was
worried about (such as address assignment and logging events) are left
intact.

> modems and NASes plus AAA backend would look like for MIP.

Yes; especially given the assumptions made in AAA about the ability to
both authenticate and authorize particular parameters.  In any event,
I think merging these is a worthwhile goal.  (And appears to be
essentially a goal of PANA, though by other means.)

> tunnels are being torn down and recreated.

I think the issues aren't so very different from the per-user address
assignment often used by corporate NASes and sometimes used by ISPs as
well (my old dial-up ISP, wing.net, gave me exactly that).  There are
particular deployments where you want to be able to associate a given
set of addresses with the authenticated link identity.

As a more subtle issue, it's much more commonly the case that a NAS
makes a "best effort" to reassign the same IP address to the same node
when it disconnects and reconnects later.  Doing this relies on at
least having the identity at address-assignment time.  If you don't do
authentication before assigning the address, then you run into a
problem: this could be an attacker trying to take advantage of the old
identity.  If you know that this is happening, you can make sure the
new guy gets a reasonably old address and that any associations (such
as DNS updates) are long since done.  If you don't know, then you
can't.

> possible with MIPv6 route optimization.

They're just more limited -- you can probably deal with home IP
address assignment cleanly, and write accounting records that have at
least the granularity of the binding lifetime.  (I'm assuming that if
the MN loses its association with the HA, then it can't receive new
packets from previously unknown CNs.  This means it has to keep that
state refreshed.)

This isn't very different from the DHCP accounting problem (when did
the node go away?) or [really] the PPPoE accounting problem (did the
PC get switched off an hour ago, or is the human just asleep?).  (The
humorous part, of course, is that PPPoE was "designed" to solve the
accounting problem.  Instead, it really just waved hands at the
underlying issue.)

> So I agree that the model should be the same, but the details might differ

Sure.  The fundamental problem, I think, is with the lack of a
reliable disconnection indication on a shared medium.  There are other
instances of this (such as, well, systems that might try to use
multiple Ethernets for redundancy and switch among the interfaces ;-}
...).

> support different methods akin to EAP.

My point was that there are actually two independent problems here:

	1. is there a connection to a AAA backend that can centralize
           the authentication and perform authorization-related
           functions?

	2. is the authentication method one that works with many
           access technologies or just this one?

All four cases are legal and reasonable.  If point (1) is true and (2)
is false, then you can have a system that does MIP-specific
authentication functions in the AAA backend but (perhaps) has generic
authorization information.  If at least (2) is true, then you are
approaching the PANA goal (but with authorization).

Supporting different methods in MIP (such as EAP) isn't actually
necessary unless you're also worried about the "authentication method
du jour" problem that PANA is trying to solve.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 14 Feb 2002 19:16:27 +0100 (CET)

> packets from previously unknown CNs.  This means it has to keep that

Correct. But it could continue refreshing existing binding with existing CNs
without involving the HA - but applying the return routability way of
securing/authorizing such binding means the HA would need to be refreshed
with binding as well even for that to work.

> du jour" problem that PANA is trying to solve.

Got it.

  Erik

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 26 Feb 2002 16:03:14 -0500

Hello James,

On Tue, Feb 05, 2002 at 09:38:36AM -0500, James Carlson wrote:
> particularly vulnerable to attack.  

Actually, in section 4.5.3 we tried to address the need for
cookie-like mechanisms as defined in ISAKMP and SCTP.  Cookie would be
effective for blind masquerade attacks when establishing a
communication channel over connectionless transport such as ICMP and
UDP.  However, if a communication channel is to be established over a
connection-oriented transport that does not have a cookie mechanism
(e.g., TCP), defining a cookie mechanism over such a transport may not
be so much useful because the transport itself subjects to blind
masquerade attack. e.g., TCP SYN attack.  So I thought that "no worse
than TCP SYN attack" would be the bottom-line requirement at this
phase in which it is not not sure which transport is better for PANA.
But I may be wrong.

BTW, do you think the cookie mechanism defined for ISAKMP is 
still useful when ISAKMP runs over TCP?

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 26 Feb 2002 13:45:07 -0800

I'd like to propose adding text to section "4.1.4 Identifiers"
in the requirements draft.

Currently it says:

   ...
    
   PAA MUST be able to create a binding between the PaC and the 
   associated DI upon successful PANA exchange. This binding is used
   for access control and accounting in the network as described 
   in section 4.1.2.

Proposal:

   ...
 
   PAA MUST be able to create a binding between the PaC and the 
   associated DI upon successful PANA exchange. This DI MUST be
   carried either explicitly as part of the PANA payload, or
   implicitly as the source of the PANA message. This binding is used
   for access control and accounting in the network as described 
   in section 4.1.2.

Also, in section 4.1.1., addition of the following text:

   When the DI is carried explicitly as part of the PANA payload, the 
   authentication computation MUST also include this field to provide
   intergrity protection for the DI.

   When the DI is carried implicitly as the source of the PANA 
   message, the protocol has to make sure that the DI's integrity is 
   protected by some other means (e.g., physical verification of 
   incoming port number of the PANA message in the case of 
   switch port number as a DI and PAA co-located with the link-layer 
   access device).

Comments?

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 26 Feb 2002 17:52:35 -0500

>    for access control and accounting in the network as described 

There is a case in which the DI is explicitly 
included as part of the PANA payload AND also 
implicitly included as the source of the PANA message.
This would be useful for somehow authenticating the implicit DI 
which is not usually integrity protected, by the following way:

(1) Check if the explicit DI == implicit DI.
(2) If the above check passes, then, authenticate 
    the explicit DI.  If it passes, the DI is considered to 
    belong to the client.

Does the explicit DI case also include this case? 

If no, how about the following for the second sentence?

"This DI MUST be carried explicitly as part of the PANA payload 
and/or implicitly as the source of the PANA message."

Thanks,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 27 Feb 2002 17:33:19 -0500

On Wed, Feb 27, 2002 at 02:23:16PM -0800, Alper Yegin wrote:

> I see what you are saying. I'll make it "carried either explicitly
> or implicitly or both".

This is also fine with me.

Thanks,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 27 Feb 2002 14:23:16 -0800

Yoshihiro,

> Does the explicit DI case also include this case? 

My proposed text doesn't require explicit DI==implicit DI. 
I think we should't say that in the requirements draft. We should
leave this to the protocol design. A protocol might be more
secure by following your suggestion, or more flexible by not making
this comparison (still has to provide security though).

alper