Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt

From: George Tsirtsis <[email-masked]>
Date: Thu, 1 Feb 2001 10:31:20 -0500

Hi Subir,

First of all sorry I disappeared but I was away on business. 

I am not sure I understand your argument regarding Application Layer
authentication. It seams to me that this will eliminate the authentication
per network layer protocol (v4/v6) but will require it per
application....which I guess is even worst :-) ...unless I missed your
point...

George

-----Original Message-----
From: Subir Das [mailto:[email-masked]]
Sent: Tuesday, January 30, 2001 8:07 PM
To: [email-masked]
Cc: DHCPv4 discussion list; [email-masked]
Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt

 Bernard,

Here is an attempt to answer your question:

 1. Authentication above layer-2 works for any link technology (e.g., home,
cable, cellular, office).

 2. Authentication at the application layer (as is proposed for BURP,  for
example),  independent of IP        address, eliminates the need to do
separate authentication for a dual stack(IPv4, IPv6).

Appreciate your comments.

 Regards,

 Subir

"Bernard D. Aboba" wrote:

> Out of curiousity, how does IP-layer auth work in a multi-protocol
> situation?
>
> For example, if I'm running dual stack (IPv4, IPv6), do I now need two
> authentications, one for each protocol? What if one auth succeeds and
> another fails? In effect, the interface is down for one protocol and up
> for another. How does this work?
>
> I think that while it's easy to advocate "doing it at the IP layer" it's
> a lot harder to describe how this would work (and why this solution would
> be better than a linklayer one).

--
****************************************************************************
****
Subir Das                         Ofc: MCC 1D-210R
Telcordia Technologies            Tel: 973 829 4959
(Formerly Bellcore)               Fax: 973 829 5888
445, South Street              E-mail: [email-masked]
Morristown, NJ 07960-6438
****************************************************************************
****

---

From: John Schnizlein <[email-masked]>
Date: Thu, 01 Feb 2001 10:49:10 -0500

At 10:36 AM 02/01/2001 -0500, George Tsirtsis wrote:
>...
>Note! We only need a signalling protocol over the access link...AAA covers
>very comprehensively how the Access Router (or in fact its AAA client)
>communicates with the AAA server to provide the Access Router with the
>correct policy/configuration/firewall for the MN.

This makes a lot of sense to me.
It also fits well with Bernard's suggestion of using IEEE 802.1x.
What is wrong with this?

At 09:57 PM 01/26/2001 -0800, Bernard Aboba wrote:
>...
>I've also often wondered why it is that we need PPP in xDSL. The Ethernet
>in the Last Mile (ELM) study group in IEEE is looking at DSL-based
>Ethernet PHYs, so that you could use Ethernet as the link layer instead.
>For this, IEEE 802.1X Network Port Authentication would be used for
>access control. See:
>
>http://www.drizzle.com/~aboba/IEEE/8021x-d10.pdf.gz
>

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 1 Feb 2001 11:04:01 -0500

Allow me to add one more....

* No packet (originated from the end node) goes through the Access Router
until this mechanism completes successfully.

Not sure about framing...I guess we will need to define transport for this
mechanism...maybe an existing one can do the job but if not...we can always
put it on top of DHCP as the draft in the subject indicates :-)

George
-----Original Message-----
From: Patrice Calhoun [mailto:[email-masked]]
Sent: Thursday, February 01, 2001 3:49 PM
To: George Tsirtsis
Cc: [email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt

> Let me agree with you entirely! So, PPP provided us with a mechanism to
> trigger AAA at the Access Router....in the absence of PPP we need some
> alternative.

Correct, and the requirements that I have are (in no particular order of
importance):
	1. Lightweight
	2. Requires minimal (ideally no) link state (besides up/down) on the

	   access router
	3. Allows for frames to be interrupted, to allow high priority
frames to 
	   take precedence
	4. has an efficient framing mechanism
	5. Has an authentication phase

The question I have is whether a new framing format is in scope, or just the
authentication mechanism?

PatC

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 5 Feb 2001 05:10:26 -0500

Erik,

Sure, it would be great to build a protocol that can work with multiple
routers on the link. Again, my initial focus was on point to point links but
shared mediums should also be looked at. PPP was point to point only and
thus could maintain state...if we design a new protocol we might try to make
it less stateful and/or find a way to destribute the result of the AAA
function (firewall settings etc).

thanks
George

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Monday, February 05, 2001 1:17 AM
To: George Tsirtsis
Cc: [email-masked]; [email-masked]
Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt

> trigger AAA at the Access Router....in the absence of PPP we need some

George,

Presumbly the protocol should work when there are multiple access routers
on the link. I don't see why we need to cripple e.g. an Ethernet to
only have one router; allowing multiple provides more efficient routing
but more importantly some redundancy.

  Erik

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 6 Feb 2001 05:14:24 -0500

Subir,

Now I am getting confused. You want "network registration" but not "access
control"...what does that mean? So you want to "register" to what? And if
someone fails to "register" what does it happen? Don't you refuse "access"?
and thus do access control?

Maybe it would help if you could explain what the LSA is for. What happens
when a node/user does not have an LSA and how you police the LSA.

Thanks
George

-----Original Message-----
From: Subir Das [mailto:[email-masked]]
Sent: Tuesday, February 06, 2001 12:26 AM
To: DHCPv4 discussion list
Cc: DHCPv4 discussion list; [email-masked];
[email-masked]
Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt

Erik Nordmark wrote:

> I understand the above.
> But, in order for access control to be affective, doesn't access control
> have to be implemented at L2 (or L1)?
> Otherwise an unauthenticated entity can just spoof its IP address to be
that
> of an already authenticated entity and gain access.

I agree,  but  we are trying to segregate the user to network registration
from
access control.  Moreover, the  proposal is not  to build an IP-layer access
control protocol.  I think, access control  via firewall/ policing  at the
access
router  is
a  policy  or architectural issue which is beyond the scope of BURP.  In
a nutshell, what we want to achieve is  a  Local Security Association (LSA)
between
the user and the network  when an user enters into a  visited network.
However,
the generated LSA between user and network can be used to help with access
control either above or below the IP layer.

>
> If access control needs to be done at L2 (or L1) what are the benefits of
> having L3 or higher protocols for authentication?

As an example,  Mobile IP clients need a L3 authentication  even if there
exists an authentication at L2.   Similarly, many IETF protocols have their
own
(either in built or extended) end-client (user-node) that interacts with AAA
infrastructure. But we need something when those protocols are absent or not
required. A  generic user registration protocol at the application layer may
help other protocols to use the same LSA for authentication without
extending
individual protocol to work with AAA infrastructure.

Regards,
Subir

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 12 Feb 2001 12:51:53 -0500

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Monday, February 12, 2001 12:25 PM
To: George Tsirtsis
Cc: 'Patrice Calhoun'; Erik Nordmark; DHCPv4 discussion list;

> I think there is temptation to integrate some of L2/L3 AAA and indeed in
> some circumstances it might even be possible....but I still think the
above
> is not the general case. To return to my favorite example of
always-on...per
> port L2 authentication could be static and subscription based. L3 AAA on
top
> of it could supply customer/user profiles as well as accounting and
> authorization to specific services.

This sounds a lot different that "provide what PPP authentication and access
control does for PPP links for any link layer".

While I can sort of understand that granting L2 connectivity is different
than granting L3 connectivity (even though PPP doesn't make such a
distinction)
I think the issue of AAA for applications was sent off to IRTF/AAARCH to do
some research. So I don't see how the last part relates to the BoF proposal.

GT> PPP confuses things because it is integrated L1/L2/L3...which reminds us
that strict layering only works in theory...but I think we are becoming too
philosophical and although I am of Greek origin I rather stick to
engineering :-)

George

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 13 Feb 2001 15:25:36 +0100 (CET)

> Erik,
> 
> Isn't AAA for applications still a different issue from AAA for L3 services?

Yes, I think it would be a very different issue.

  Erik