Subject: RE: on PANA justification was: RE: draft-ietf-pana-usage-scenarios-00.txt

From: <[email-masked]>
Date: Fri, 8 Feb 2002 09:34:05 -0600

I am really surprised why there is so much confusion and concern
about what PANA is trying to do. If you read the charter, it spells
out the problem and scope of the work quite clearly. The problem
that we are working on is fairly simple and I agree that there do 
exist solutions in place today for network access authentication.
However we are trying to develop a lower layer independent messaging
protocol that would authenticate users/devices for network access.

-Basavaraj

> 
> 
> Well,
> 
> Whether the justification holds it is a matter of opinion and 
> it seems we
> have different ones. You guys that think there is no reason 
> for PANA make
> two assumptions:
> 
> 1- PPP takes care of all point to point scenarios and can 
> even run on top of
> non point to point (e.g.: PPPoE)
> 2- 802.1X takes care of everything else.
> 
> The rest of us think that there is need for PANA because:
> 
> 1- PPP does the job on point to point links but it is too 
> much state and
> thus is no good for non-point to point.
> 2- 802.1X does not take care of everything else because i) 
> not all link
> layers are 802 based and ii) 802.1X authentication is 
> meaningless when what
> you are looking for is access to IP layer services!
> 3- We need a lightweight authentication mechanism that works 
> over any link
> layer in a consistent way because authentication should 
> become fundamental
> part of the Internet architecture.
> 
> So, as long as there are enough people that think the 2nd set 
> of arguments
> is good enough justification for PANA we are going ahead and 
> people with
> objections should at some point give way to rough consensus.
> 
> The purpose of having BOFs before turning them into WGs is exactly to
> establish that rough consensus. 
> 
> Following the decisions to go ahead, people who oppose the 
> work have a very
> hard case to make to convince others to stop the work and go 
> home and IMHO
> this should only happen if either significant part of the 
> people that are
> interested on the subject give up or the IESG thinks that 
> this is going
> nowhere. At the end of the day if you think that what PANA is 
> trying to do
> is nonsense let it be...if you are correct the work is likely 
> to implode and
> the protocol will never be used. 
> 
> George
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Jacques Caron [mailto:[email-masked]]
> Sent: Friday, February 08, 2002 10:09 AM
> To: Hesham Soliman (ERA)
> Cc: Hesham Soliman (ERA); Yoshihiro Ohba; [email-masked]
> Subject: RE: draft-ietf-pana-usage-scenarios-00.txt
> 
> 
> At 10:38 08/02/2002, Hesham Soliman (ERA) wrote:
> >=> I think we're revisiting the reasons for
> >the creation of this WG, for some reason.
> >I don't see the point since we already have
> >a WG.
> 
> As I already pointed out, a WG or a charter is not a justification by 
> itself. A WG might very well be created to try to solve a 
> problem that was 
> thought to exist, but actually doesn't :-/
> 
> Jacques.
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
>

---

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

[email-masked] writes:
> out the problem and scope of the work quite clearly.

Actually, no, it does not.  I think that's part of the problem.  The
lack of clarity of the requirements and usage scenarios (which was the
origin of this thread) makes this situation worse.

Since you mention the charter:

> The AAA working group is specifying the Diameter protocol for
> communication between servers i.e. where Radius is currently being
> used. There is currently no general protocol 

Is this necessarily a bad thing?  Why?  If there is a general
protocol, how does it interact with the specific link layers in use?

>to be used by a user's
> device when wanting network access,

What, precisely, is defined as "network access?"  It's quite clear
that we each have different answers in mind when we look at that
phrase.  Is "network access" defined as L2 first-hop permission to
pass L3 packets?  Is it defined as gateway router permission to pass
IP packets to a wider Internet?  Is it defined in some other way?

If the answer is at L2, then the existing mechanisms appear to be
sufficient for the purpose.

If the answer is at L3, then I have a host of questions:

	- What happens on subnets that have multiple egress routers
          (for, say, reliability reasons)?  Does a client authenticate
          itself to each egress router?

	- How does this interact with HSRP/VRRP?  What are the
          security relationships?

	- If there are multiple egress routers that go to different
          networks (for, say, choice of providers as suggested in one
          of the drafts), then how are broadcast and multicast
          conflicts resolved?

	- If both IPv4 and IPv6 are supported, do I authenticate
          separately for each?  Or once for both?  What if other
          network layer protocols are in use?  Are they controlled by
          PANA or not?

> and this WG will attempt to fill
> that hole. That is, a protocol between a user's device and a device
> at the network access point where the network access device might be
> a client of the AAA infrastructure.

In *deployed* solutions today, that is done with L2 mechanisms, and
the provider's security models depend on this.  What are the issues in
bumping this up a level in the stack and leaving L2 unprotected?

> Currently the authentication mechanisms in PPP are being used for
> many wired access scenarios as well as some wireless access, which
> requires using PPP framing for the data packets.  This is not viewed
> as the optimal solution in the cases where framing protocols already
> exist.

As described before, this description is wrong.  Framing isn't an
issue.

> Also, IEEE 802 is working on 802.1X which provides EAP
> authentication limited to IEEE 802 link layers.

802.1X is out.  Does this mean that 802 is solved and thus not subject
to PANA?  What is the relevance of this?

> Network access technologies for wired and wireless media are
> evolving rapidly. With the rapid growth in the number and type of
> devices and terminals that support IP stacks and can access the
> Internet, users can potentially use a single device having the
> capability of attaching via different multiple access media and
> technologies to interface to the network. The model for providing
> the users' information to the network for authentication,
> authorization or accounting needs to be the same and NOT be tied in
> to the underlying access type.

Sure.  But is that a function of the transport that carries the
authentication protocols or a function of the chosen authentication
protocols and the AAA infrastructure?  I submit that it's the latter,
while PANA addresses only the former.  There's a disconnect here.  The
problem isn't in the wrapping of the EAP packets on the wire, the
problem is that, despite the existing described protocols, people are
deploying different authentication methods in different scenarios.

How does PANA address that?

> - A device (on behalf of a user) to authenticate to an agent in the
> local network. The agent might be non-local, but at the boundary of
> some AAA-equivalent function. The agent is called PANA
> Authentication Agent (PAA) in this charter.

Why are "users" necessarily referenced here?  So long as the
provider's billing and security model is maintained, there doesn't
actually need to be a user.

> - The device to discover the IP address of the PAA. 

This assumes the solution.

> - Outside of the scope of the protocol, allows for the PAA to
> install access control mechanisms in the network, based on the results
> of the AAA protocol exchanges. This follows the model of current
> Radius being able to provide filtering rules to NASes.

This leaves us in the odd position that PANA may supply IP filters but
won't actually allocate the node's IP address.  Given that the node's
IP address often figures into the content of the filters, does this
actually work?

> A naive view of a PANA protocol would just be to define how to carry
> EAP (RFC 2284) messages in an IP based protocol. However, EAP makes
> certain assumptions about PPP like link-layers such as:

Again, the form of the solution is assumed at this point.

> - The link-layer is point-to-point i.e. a single NAS or Access
> Router is involved in the EAP exchange. For PANA there is a desire
> to be able to support redundant ARs on multi-access link layers
> where inbound and/or outbound packets might use more than one AR.

Authentication is generally defined as one entity proving its identity
to another.  The relationship is one-to-one.  I don't think I fully
understand the 'one-to-many' authentication model.

> - The link-layer providing a disconnect indication. PANA should not
> make this assumption. The assumption affects both the ability to
> tell when the session has ended from an accounting perspective, and
> it affects the frequency at which the device needs to be
> reauthenticated.

This is somewhat false.  PPP can work on links that don't provide
disconnect information.  The decision about what "sessions" are and
how much reauthentication is necessary is mostly an implementation and
deployment matter.

> A possible way to address the need for more frequent
> re-authentication is to have the first authentication, using the AAA
> infrastructure and the assumed shared secret between the device and
> its AAA home domain, create a security association between the
> device and the PAA. Then re-authentication can be done using this
> security association without involving the AAA infrastructure. Note
> that this local security association is between a pair of entities:
> the device and the PAA. It is not intended to be viewed as some
> general security association between the device and the operator of
> the access network. In fact, such general security associations are
> outside the scope of PANA.

If you don't have general security associations, then I suspect you
cannot achieve the one-to-many authentication goal.

> The PANA protocol needs reliability and congestion ontrol, taking
> into account that the PANA protocol needs to be able to operate over
> multiple router hops. The congestion control principles are
> documented in RFC 2914.

Where exactly is the requirement that PANA works over multiple router
hops?  What drives this?  What are the security implications?

> The protocol must support both IPv4 and IPv6, but given that the
> MOBILEIP WG is building Mobile IPv4 specific solutions to this
> problem, the urgency for solutions are likely to be higher for
> IPv6. The protocol must not assume a particular method of IP address
> configuration. In particular, it must not interfere with standard
> techniques and protocols like IPv6 stateless address
> autoconfiguration (including the temporary addresses specified RFC
> 3041) and DHCP. This implies that it is desirable that the PANA
> protocol be independent of IP address configuration.

That doesn't follow.  "Not interfering" doesn't mean the same thing as
"independent of."  In addition, IP address assignment *is* a security
issue, at least for IPv4 networks.  By placing PANA as independent of
IP address assignment, PANA is made less desirable for IPv4.

> The problem

So, then, given that there are existing mechanisms, what justifies
creating a new one?

Assuming PANA becomes popular, providers and implementors will be
forced to support both and integrate both into their authentication
services.  How does adding one more protocol to the mix simplify
things?

-- 
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: Erik Nordmark <[email-masked]>
Date: Tue, 12 Feb 2002 23:00:56 +0100 (CET)

> protocol that would authenticate users/devices for network access.

I think the "interaction/relationship with 802.1X and PPP authentication"
piece is the one which is the largest source of confusion.

  Erik

---

From: subir Das <[email-masked]>
Date: Wed, 13 Feb 2002 09:44:40 -0500

> piece is the one which is the largest source of confusion.

=> If I recall correctly, we kept this piece to avoid the confusion. What we
can do is to
     write up this document quickly. On the other hand, if we try to write
this draft before
     finalizing the requirements and framework specification drafts, we may
miss some important
     things. Comments?

    Subir

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 13 Feb 2002 16:17:44 +0100

>      finalizing the requirements and framework specification drafts, we may

I think starting working on the draft of the interaction between
802.1X and PANA now would make us notice things that would otherwise
be missed for the requirement and framework documents.

The 802.1X interaction document should not be finalized until the
requirements and framework is out, of course.

I haven't seen much discussion on how PANA will relate to the 802.11
distribution system, 802.11 context transfers, and roaming in general
here, and I'm having some difficulties understanding how they are all
intended to fit together.

(What is it with the '=>' quotes, too long lines, and incorrect long
line wrapping used here?)

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 13 Feb 2002 09:54:18 -0800

> requirements and framework is out, of course.

I agree 100%! Both documents can benefit from each other.

alper