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

From: Erik Nordmark <[email-masked]>
Date: Fri, 2 Feb 2001 09:25:57 -0800 (PST)

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

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.

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

  Erik

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 3 Feb 2001 00:08:08 -0800

>have to be implemented at L2 (or L1)?

If access control is done at L3, then you would presumably need
access control within every L3 protocol, or risk attack on the protocols
for which there was no access control. Whereas if you did access control
at L2 then it would apply to all L3 protocols.

Also, one needs to be clear about *what* is being controlled -- in
L2 access control, it is typically access to the port. Whereas with
L3 access control, it is typically access by the host. The latter
implies more state kept on the NAS.

These would be strong arguments for L2 in a traditional multi-protocol
environment (IPv4, AppleTalk, DECNET, IPX, NetBEUI, SNA, etc.) where
device cost is an important concern.

However, in an all-IP network (IPv4, IPv6), where devices can be
much more capable than they were in the 90s, I'm not clear that the
argument remains compelling. One can think of access control at each L3 as
somewhat akin to negotiating both IPCP and IPv6CP within PPP.

So the question that comes to mind is "what advantages does one
gain by this approach?" For example, can access control be done better
at L3 than at L2 due to facilities existing in IP or TCP? (e.g.
fragmentation,
reliable transport, etc.) And are any important L2 facilities lost as
a result? (L2 negotiations)

>of an already authenticated entity and gain access.

That's why authenticated DHCP isn't an access control mechanism ;) But
the need to link BURP to DHCP is far from clear.

---

From: Subir Das <[email-masked]>
Date: Mon, 05 Feb 2001 19:25:50 -0500

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

> 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: Subir Das <[email-masked]>
Date: Mon, 05 Feb 2001 19:33:11 -0500

> at L2 then it would apply to all L3 protocols.

My understanding is if we do it at the application layer and create a Local
Security Association (LSA), then network can make use of that LSA for
other L3 protocol if it is necessary. Am I missing something?

> device cost is an important concern.

    I agree.

> a result? (L2 negotiations).

We say nothing about access control. Traditionally, L2 or L3 protocols have
their own schemes and they never merged to a common platform so far. Is it
that IETF has not paid much attention to lower layers or it is beyond its
scope? On the other hand, in the real world there will always be multiple
solutions from many standard bodies.

> That's why authenticated DHCP isn't an access control mechanism ;)

   This is my understanding too.

> But the need to link BURP to DHCP is far from clear.

Is it necessary to link BURP to DHCP while we have multiple approaches
(IPv4 autoconfiguration, IPv6 stateless autocnfiguration) to configure a host
in absence of DHCP?

Regards,
Subir

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 11 Feb 2001 21:52:40 +0100 (CET)

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

I think a BoF and potential subsequent WG needs to look at a problem which,
when solved, provides some benefits.
I don't see "user registration" i.e. auhentication without any access control
as providing any benefits.
Of course, the above doesn't mean that the authentication and access control
parts need to be tangled together - they can very well be different functions
even provided by different protocols.
But the solution needs to include both.

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

The mobile IP L3 authentication is made to the home agent, right?
If mobile IP runs on an infrastructure which already has L2 AAA functionality,
all that mobile IP needs to provide is the home agent authenticating the
mobile to avoid some imposter redirecting traffic.
But the access control and accounting could all be done at L2.

   Erik