Subject: List of Open Issues III

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 13 Feb 2002 18:51:05 -0800

Reinaldo, all,

> List of Issues that are open/need clarification

It'd be good to clarify whether these issues are only limited to
the requirements draft or general issues on PANA.

> 1 - Authorization (Open)
>
> Should it be in-scope? To what extent?
> In a real network can we have a pure authentication protocol?
>
> (Alper) Requirements draft has a position on this. Regarding more detailed
> authorization, my personal take is "not now, can be done later".

Why is this an open issue?

>
> 2 - Should PANA duplicate functionalities already present in other
> protocols?
> (closed as Tue, 12 Feb 2002 14:51:08 -0500)
>
> (Alper) 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"
>
> (subir) I agree with Alper and Hesham. We should avoid spending time in
> discussing a topic like this. We know many protocols have some
> common functionalities and goal. Moreover, we have specific charter item
> to deal with as mentioned above.
>
>
> 3 - Notion of is actually being authenticated: User ID vs Link
> Layer ID (closed as Tue, 12 Feb 2002 0:50:10 +0100)
>
> Requirements draft is clear.
>
>
> 4 - DI as an access independent parameter. (closed as Tue, 12 Feb 2002
> 0:50:10 +0100)
>
>
> You may have:
>   - access independent authentication
>   - access dependent authentication
>
>  In the former case, you authenticate based on an
>  access independent identifier, such as a NAI. In the
>  latter case you also
>  validate/authenticate/ensure-the-integrity-of  an
>  access dependent Device Identifier. (This is just a
>  word referring to an IP-address, link-layer address,
>  flow-state-descriptor or some other access dependent
>  divice information.)
>
>  Thus, the conclusion of the thread was that the
>  Device Identifier is OPTIONAL in the PANA protocol.
>  PANA accommmodates both access independent and
>  access dependent authentication.
>
> 5 - Device Identifier and Multicast Addresses. (Open)
>
> In the requirements it is said that.
>
> "Device Identifier (DI)
>
> The identifier used by the network as a handle to
>
> ...<snip>...<snip>...
>
> At most one PANA client should be associated with a DI
> on a PANA authentication agent. "
>
> Given that the DI can an IP address, this means that
> in the multicast case you cannot use DI as an
> identifier (since several clients would be associated
> with a DI), or we need to change the above definition
> a little.
>
> So the main question is: Would that be a case where
> you want to grant access to all members of a multicast
> group without caring to know each client individually?
>
> (subir) Want to deal with Mutlicast separately

(alper) not sure why we have to deal with this :)
Seriously, why does PANA have to handle this case?
Do you see a need, or do other similar protocols handle
this already?

>
>
> 6 - Addtional Security Requirements - Paal (open)
>
> Current Text:
>
> "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")."
>
> Another place in the draft we find:
>
> "Both the PaC and the PAA MUST be able to initiate both the initial
> authentication and the re-authentication process."
>
> I see a possible contradiction between 1 and 2. Re-authentication is
> often based on Challenge/response. Now, I think 1) and 2) would rule
> out EAP MD-5 challenge/response (e.g. carried by say EAP-over-ICMP) and a
> lot of other re-authentication methods as well. The reason is that 1)
> and 2) makes reflection attacks really easy to launch, IMO.
>
> Say, an unauthenticated malicious node pretends to be an
> authenticated PaC. It receives a MD-5 challenge from a PAA. It buffers the

> challenge, and sends a new request message back to PAA containing exactly
> the
> same challenge. PAA returns the answer, which is the answer to the first
> request. The malicious node managed to re-authenticate!

I don't understand how you get to this special example from
above mentioned two statements from the requirement draft.
You are making assumptions, such as use of challenge, and
especially in a unsecure way....

>
> I think the intention of the former is not to develop new solutions.
> However,
> I think the following requirement would fit the purpose of our WG
> better:
>
> "PANA MUST NOT define new security protocols or mechanisms. Instead
> it must be defined as a "carrier" for such protocols, and it MAY pose

I'm not sure if your example is special to PANA...

Maybe we should say "If PANA uses challenge-response method for
re-authentication, it MUST be protected against reflection attacks"
or something like that..

> additional requirements to the protocols that it carries. PANA MUST
> identify which specific security protocol(s) or mechanism(s) it can carry
> (the "payload")."
>
> As a sidenote:
>
> Additional requirements on challenge/response methods to solve the
> Reflection Attack problem could be one of the following:
>
> 1) PAA and PaC MUST use different keys for re-authentication in both
> direction.
>
> But I prefer the following:
>
> 2) A node cannot send the same challenge that it receives. This can
> be enforced by requiring Authenticator MUST append the authenticatee's
> NAI (or temporary identity) to the beginning of a challenge-string, and
> to require that authenticatees MUST parse the challenge and validate
> that the identity in the challenge is correct before returning the MD-5
> digest.
>
>
> 7 - Expand on the Interactionsinteraction/relationship of PANA with
> 802.1X and PPP authentication - Erik et al (open)

This is a separate draft....

>
>
>
> Text to be added
> =================
>
>
> 1 - Non multi-access aspect of PPP - James Carlson - Text to be added
>
> 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 - Text to be
> added
>
>
> 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.
>
> 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?
>
>

alper

---

From: James Carlson <[email-masked]>
Date: Thu, 14 Feb 2002 07:51:22 -0500 (EST)

> > 1 - Authorization (Open)
[...]
> Why is this an open issue?

For one thing, it seems to be the case that there are situations where
it's not possible to communicate via IP until the authorization has
been done, and that authorization can't be done until authentication
has completed.  The example case I gave was an 802.11 network that
provided access to multiple ISPs based on VLANs behind the access
point.  In order to make that work, there needs to be a way for the
access point to determine the 'right' context for a given end node.

This problem is roughly analogous to the problems faced with 'equal
access' requirements on shared networks.  (But uses trendy terms like
"wireless" and "VLAN.")

The solution to that involves sending some sort of identifier from the
end node to the access point to select the desired network.  The only
question left is whether any authentication is involved.  If it's not
involved, then the administrator has no control over which nodes may
access which VLANs.  If it is involved, then there needs to be a way
to establish credentials for the end node.  This is then complicated
by the fact that the end node can't determine whose IP subnetwork (and
therefore which address) will be used for authentication.

One PANA-based solution might be to allow the end node to pick an
arbitrary address, and put a proxy PAA in the L2 access node.  This is
sort of equivalent to the way compulsory L2TP tunnels are usually
implemented: the access node looks at enough authentication
information to make a determination of where to send the tunnel.  It
can get pretty ugly.  Especially so since the end node will have to
renumber after getting connected, and there's no obvious way that the
end node will know that this is even needed.  That is to say: one of
the suggestions originally put forward (not by me ;-}) was to use a
temporary address to do the PANA authentication in order to open the
IP floodgates for other protocols, including IP address assignment.
But how is the end-node supposed to know that the IP address that it
has isn't permanently valid?  And if there's a magic "please do
something to get a new IPv4 address for yourself" message from the PAA
to the PaC, how is this protected against attack?

Another case where the problem occurs is with systems -- in common use
by ISPs -- that grant IP addresses in different ways based on the
outcome of authentication.  Some end nodes may get fixed IP addresses.
Some may get dynamic assignments.  To use PANA here means that you
have to duplicate the BOOTP/DHCP trick of using a zero source address
and rely on the access node to hot-wire an appropriate ARP entry and
fill in the source address if it needs to do relaying.  Again, this
can easily run into address-assignment problems in the IPv4 case.
(That is, there are cases where the L2 relay needs to be able to
assign an IPv4 address, but cannot until it authenticates the request
in some way.)

> > 5 - Device Identifier and Multicast Addresses. (Open)
[...]
> > with a DI), or we need to change the above definition

If it's an IP address, isn't it basically a *source* IP address?
Under what conditions should an end node ever be using a multicast
address as its source address?

I think the DI is still a little fuzzy.  It may contain link-related
information:

	Depending on the access technology, identifier might contain
	any of IP address, link-layer address, switch port number,
	etc. of a device.

But since the access request comes from the end-node itself, there are
a number of serious problems:

	- How does the end-node know the right link-layer information
          to insert?  In some cases it may (its own MAC address,
          perhaps), in other cases it might (its own telephone number
          or E.164 address, though it probably cannot or should not
          guess at the numbering plan at the other end of the link),
          and in others it almost certainly cannot (the switch port).

	- Why should the PAA trust the end node to insert the right
          DI?  Since this is the 'only' authentication to occur, and
          succeeding grants full network access to the client,
          couldn't the client lie about the DI in order to get access
          on a "privileged" subnetwork?  (I know; this veers off into
          authorization territory, but it's fundamental to the
          architecture.)

Is the access node expected to augment the DI on the fly?  If it does,
then what are the implications for validating the message?  What are
the implications for the requirements placed on parsing the contents
of the DI at the access node (to make sure that no "unwanted" end-node
information leaks through)?

Should such augmentation be specific or left up to implementor
discretion?  If it's the latter, then what happens with
interoperability?

> especially in a unsecure way....

Agreed; this is a known problem with somewhat known solutions.  The
thing that PANA brings to the table is a new threat model.  Since the
PAA is an IP node, it makes a handy and available oracle for anyone
trying to impersonate a PAA -- and only networking skills are
required.  This is likely to be much easier than (say) finding a way
to both jam a wireless access node and use that node as an oracle.

-- 
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: Yoshihiro Ohba <[email-masked]>
Date: Thu, 14 Feb 2002 16:01:32 -0500

> to the PaC, how is this protected against attack?

DHCP reconfiguration can triggered by the server, and the end node can
also start from a zero address before it is authenticated.  I'm not
sure what kind of attack you mentioned in the last sentense, but in
general, some sort of security is available after successful
authentication and we can utilize that for protecting against attack,
IMHO.

I feel from the recent discussion that it would be difficult to reach
rough consensus if the discussion point is whether a solution is
"ugly" or "layer violation" without having a clear criteria on
ugliness or layer violation.  

> assign an IPv4 address, but cannot until it authenticates the request

I think if we have the first solution at least, then this case would 
not be necessary.

Yoshihiro Ohba

---

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

Yoshihiro Ohba writes:
> DHCP reconfiguration can triggered by the server,

I assume you mean RFC 3203.

> and the end node can
> also start from a zero address before it is authenticated.

Which requires the zero-address handling hacks used by BOOTP/DHCP and
necessarily means that the L2 device *must* assign an address in order
to act as a proxy for the PAA.  The L2 id (MAC address) isn't usable
for routing the replies outside of the L2 domain, so the PAA can't use
it.  It needs an IP address, and I think you're back where you
started.  (That's the proxy problem I was referring to.)

>  I'm not

Send a FORCERENEW and preload DHCP replies so that the client sees the
bogus DHCP server before any other.

> ugliness or layer violation.  

Agreed.

> I think if we have the first solution at least, then this case would 

Perhaps.  The L2-related issues need exploration.  Should the node be
able to use an unauthenticated L2 as a free party line?  If
authentication and authorization occur some distance from the L2
access node, what keeps this from happening?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 14 Feb 2002 17:04:08 -0500

> I assume you mean RFC 3203.

Yes.

> started.  (That's the proxy problem I was referring to.)

I'm not sure what the assumption behind this, but one solution would be:

(1) AP connects the unauthenticated device to an unauthenticated VLAN.
(2) The device performs DHCP for obtaining an address 
    on the unauthenticated VLAN.
(3) The device performs PANA (if needed).
    If authentication is successful, then PAA (co-located with AP) 
    sends some access control commands (outside PANA) 
    to the AP and DHCP server on the connected VLAN.  Then,
    a1)  The AP connects the device to one of authenticated VLANs.
    a2)  The DHCP server sends FORCERENEW to the device.
    a3)  Device obtains an IP address on the authenticated VLAN.
      
> bogus DHCP server before any other.

Essentially, bogus FORCERENEW can be sent from any VLAN including
authenticated VLANs.  So, I think the security impact is not different
from the solution based on L2 authentication.

> able to use an unauthenticated L2 as a free party line?  

It depends on the type of service.

> If

PAA can be put on the L2 access node if the node also speaks IP and
PANA.

Yoshihiro Ohba

---

From: subir Das <[email-masked]>
Date: Thu, 14 Feb 2002 17:30:17 -0500

James Carlson wrote:
> 
> subir Das writes:
> >   If I undertand you correctly, you are assuming that DI is
> >   an IP address and at the beginning there is no IP connectivity from
> > the
> >   end node.
> 
> No; I'm not assuming anything in particular about DI at this point
> (although that's clearly another wrinkle to the problem).  I'm
> assuming only that the end node uses IP datagrams to carry the PANA
> messages.

  I got it.
> 
> > Now if DI is not an IP address or for the sake of argument,
> > if
> >   we assume that there exists always an IP level connetivity from the
> > end node,
> >   before performing PANA do you anticipate other problems (except
> >   some security attacks)?
> 
> That's exactly the problem.  PANA is assuming that there's IP level
> connectivity from the end node before the authentication has been
> done.

  Do you see any fundamental problem with this assumption? If link layer
provides 
  device authentication, for example, the way today's cellular phone
works and then 
  PANA runs on top of that to provide Pac level authentication.
  
> 
> >   According to the requirement draft, it is the  Pac identifier which is
> >   being authenticated and PAA keeps a table for binding DIs to Pacs once
> >   authentication is successful. IMO, PAA trusts on Pac identifier not
> > the
> >   DI.
> 
> If the DI isn't authenticated, is it of any value at all?

  If you do the device authentication at the lower layer and then trust
the 
  Pac who provides you another indentifier for authentication. Is it not 
  sufficient?

> 
> The requirements draft actually states this:
> 
>    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.
> 
> Note that it includes the identifier as part of the credentials (which
> is odd, since it's really an identifier, not an authenticator) and
> that it at least *implies* that DI is part of the PAA's authorization
> function.
> 
> Further, since the communication is between the PaC (which is
> apparently identically the end-node), this DI value comes from the
> PaC.  So why is it unauthenticated but trusted?

  Are you suggesting that we should do both device authentication as
well 
  as Pac authentication? 

  Subir

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Thu, 14 Feb 2002 18:50:22 -0800

Jim,

>           and in others it almost certainly cannot (the switch port).

DI might be carried implicitely or explicitely. Requirements
draft doesn't say anything on this. Solutions probably have to.

The source IP address (if there's one), or the source mac address
can be used as a DI. These are implicitely carried 
(no additional payload).

>           DI?  Since this is the 'only' authentication to occur, and

Why do you trust authenticated nodes that they wouldn't
respond to arp on someone else's behalf? Same answer...

>           on a "privileged" subnetwork?  (I know; this veers off into

Well, authentication succeeds, authorization fails. (remember the
binary result on authorization).

> Is the access node expected to augment the DI on the fly?  If it does,

During the PANA authentication, or after the authentication? Which
one is the issue here?

alper

---

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

>   PANA runs on top of that to provide Pac level authentication.

What precisely is the difference between device and PaC
authentication?

I agree that cellular phone authentication isn't linked into the
expected AAA mechanisms.  Isn't that the real problem?  Why not attack
that root problem rather than layering another authentication atop
that one?

(At least the cell phones that *I* know are inherently point-to-point
devices -- I can't send signals directly to another cell phone -- and
that suggests a particular L2 solution that already has authentication
and authorization mechanisms.  Perhaps there are other sorts of cell
phones.)

>   Pac who provides you another indentifier for authentication. Is it not 

No, it's not.  First of all, as I pointed out, it's not necessarily
the case that the PaC even knows the right information to put in the
DI: if it's a switch port or similar, then either the PaC is going to
need to have a human read off the label (and hope he types well) or
the L2 device is going to have to augment the DI on the fly (which
leads to parsing problems unless it's just a simple overwrite).

To the extent that the DI forms a part of the device's identity, it
must be covered by the authentication performed.  Unauthenticated bits
of identity used for authorization are a hazard because they allow
users who are authenticated for one purpose to do things for which
they aren't authorized.

>   Are you suggesting that we should do both device authentication as

I'm actually suggesting that these are one and the same.

---

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

>     a2)  The DHCP server sends FORCERENEW to the device.

Really?  How does the DHCP server on the authenticated VLAN know about
the new device?  (And, even if it does somehow know about this new
arrival, what if the end device does something perfectly reasonable
such as validating the source of the FORCERENEW message?  Do all of
the DHCP servers on all of the authenticated VLANs have the same MAC
and IP addresses?  Or does the client accept such a message from just
anyone?)

>     a3)  Device obtains an IP address on the authenticated VLAN.

... and, likely, the device has to repeat the PANA exchange with a PAA
native to the authenticated VLAN, right?

If the PAA is co-located with the AP, then certainly some simple
mechanism could be used for authorization.  This is essentially the
same as is done today with existing L2 authentication mechanisms.  But
one of the clear goals of PANA is to have the PAA located *far* behind
the AP such that multiple local access points can rely on the same
PAA: that's the basis of the roaming-friendly and rechallenge goals.

So, since this is really the same as L2 authentication in the
important respects (except perhaps for a much higher number of message
exchanges required), isn't it still the case that this is something
for which PANA is inapplicable?

> from the solution based on L2 authentication.

Not quite.  PANA appears to allow unauthenticated devices to use the
local L2 subnetwork without bothering to authenticate.  That's one of
the fundamental requirements: unauthenticated access to the L2 is
needed in order to pass IP datagrams containing PANA messages and to
support any address assignment mechanisms in use (whether DHCP or
Neighbor Discovery or something else).

This changes at least the nature of the problem; it's an important
security issue.

> PAA can be put on the L2 access node if the node also speaks IP and

That appears to ignore the "if" in my question.

Co-locating does solve the problem but, as I mentioned above, it also
makes PANA equivalent to L2 authentication in terms of the roaming and
rechallenge issues.  Since PANA may have fewer authorization hooks[1],
and L2 mechanisms already exist with robust authorization and
accounting (which we haven't discussed), where does that leave us?

[1] it's been hard to nail down this requirement, so all I can say is
    "may."

---

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

> draft doesn't say anything on this. Solutions probably have to.

OK.

> can be used as a DI. These are implicitely carried 

There's no way that the source MAC address can be carried implicitly
if there are any routers in the way.  Would that be a requirement that
all roaming be done within a single bridged subnetwork attached to a
PAA?

There's also no way that any other link-associated information (such
as switch port number, Calling Party Identification, or other outside
data) could be carried past the first L2 hop unless it's in an
explicit DI.  It's that bit that's a problem.

> respond to arp on someone else's behalf? Same answer...

ARP security (or lack thereof) isn't really at issue here (though I
agree it is a broader problem).  The issue at hand is why PANA is
trusting the DI to be used for authorization decisions without
authenticating the source of the DI data.  The requirements draft
says:

   Device Identifier (DI)

         The identifier used by the network as a handle to control and  
         police the network access of a client.

If this isn't from a trusted source, how can it be used to control or
police anything?

And, for the bits that the PaC *cannot* know (such as switch port
number), how does it work at all?

> binary result on authorization).

How is that the case?  The PAA doesn't have any direct knowledge of
the actual L2 attachment in use.  According to the language in the
draft, it has to believe that the PaC is telling the truth.  How can
it validate any of the authorization information?

> During the PANA authentication, or after the authentication? Which

During -- when the first "please grant me access; here's my DI and
credentials" message is sent by the PaC.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 15 Feb 2002 17:01:39 -0500

On Fri, Feb 15, 2002 at 07:16:22AM -0500, James Carlson wrote:
> the new device?  

Please read (3) carefully.  PAA can sends some access control commands
(outside PANA) to the DHCP server.

> (And, even if it does somehow know about this new

If validating the source of FORCERENEW message is required for L3
authentication, the same thing would apply to L2 authentication, since
bogus FORCENEW message can also be sent from authorized devices.

> PAA: that's the basis of the roaming-friendly and rechallenge goals.

Good point.  We need tradeoff discussion on location of PAA, since the
two goals (i.e., roaming-friendly and the above VLAN example) seem to be
competing.

(Note that if PAA is on AP for some reason and seamless roaming is 
 needed, then something like seamoby context transfer would be necessary, 
 but this part is out of scope of PANA.)
 
> for which PANA is inapplicable?

My position now is anything is possible for both L2 authentication and
L3 authentication if we are allowed to use any method.  You can
continue to show me counter-examples for which PANA is inapplicable, 
but I don't think other people are interested in them ;-)

> Neighbor Discovery or something else).

Even L2 authentication starts from unauthenticated access to the
point-to-point segment, and security attack is possible during the
bootstrap period.  This is clear by replacing the word "DHCP and ND
messages from bogus IP node" with "bogus beacon and other management
frames from bogus AP".

> This changes at least the nature of the problem; it's an important

Also for L2.  Just the layer is different, I think.

Yoshihiro Ohba

---

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

> all roaming be done within a single bridged subnetwork attached to a

If PAA is one hop away from the PaC, then the MAC address is not a
problem. Depending on where the PAA is located (which can be set by
the PANA solutions) some types of DI might not make sense. I think
solutions have to define the types/families of DIs supported.

> explicit DI.  It's that bit that's a problem.

OK, so this suggests "Either PAA must be one hop away or certain
types of DIs must be carried explicitely". Fine.

> If this isn't from a trusted source, how can it be used to control or

I think you are suggesting that the DI should also be taken into
authentication calculations. So this leads to DI as explicit payload,
I guess.

> number), how does it work at all?

Hmmm, I'm not sure about this one...

> it validate any of the authorization information?

After a successful PANA exchange, PAA sets the access control
by communicating with L2 access devices. This should prevent
potential problems associated with the PaC lying about
its DI.... (if, I understood your concerns correctly :)

Jim, can you give us an example of how can a PaC can gain
benefit by lying about its DI... (for illustration)

alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 18 Feb 2002 08:26:17 -0500

Additional notes on my reply.

> (outside PANA) to the DHCP server.

Note: access control commands can be sent to remote DHCP servers.

> two goals (i.e., roaming-friendly and the above VLAN example) seem to be

Note: if the same PAA is reachable from every VLAN, it is possible to
put the PAA far behind the AP and thus the two goals could be
compatible, IMHO.

[...]

Yoshihiro Ohba

---

From: John Schnizlein <[email-masked]>
Date: Mon, 18 Feb 2002 09:06:00 -0500

>Note: access control commands can be sent to remote DHCP servers.

This appears to imply yet another protocol definition for communication
between  the PAA and the DHCP server. Does anybody have a count of the
number of protocols implied by the discussion so far?

Partial list:
PAA -> DHCP server 
in addition to 
PaC (authentication) -> PAA
PaC (discovery) -> PAA
PAA (access control) -> edge router or switch (possibly multiple)
Are there others?

John

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 20 Feb 2002 20:45:30 -0800

John,

> number of protocols implied by the discussion so far?

I'm not sure about that one...

> PaC (authentication) -> PAA

This above two is one! We don't consider discovery of dhcp
server a separate protocol, right? Discovery of the server
is a part of the protocol.

> PAA (access control) -> edge router or switch (possibly multiple)

We don't need a new protocol for that. There are protocols already
designed for that. MIDCOM, COPS.... Do you see a new requirement
from PANA that is not satisfied by any such existing protocol?

alper

---

From: John Schnizlein <[email-masked]>
Date: Thu, 21 Feb 2002 07:06:56 -0500

At 11:45 PM 2/20/2002, Alper E. YEGIN wrote:

>> >> > Really?  How does the DHCP server on the authenticated VLAN 
>> >> > know about the new device?
>> >>
>> >> Please read (3) carefully.  PAA can sends some access control 
>> >> commands (outside PANA) to the DHCP server.
>> >

This is exactly the proposal Yoshihiro Ohba made above (Please read...).
Do you disagree with his proposal, or advocate this protocol?

>is a part of the protocol.

There was discussion on this list of different ways for the PaC
to discover the PAA. The way DHCP does it is explicit configuration
in the access router's relay agent of the address of the DHCP server.
If the relay-agent approach is taken, this protocol is replaced by
a required behavior in all access devices. Is there consensus for that?

>from PANA that is not satisfied by any such existing protocol?

Are you proposing that the PAA also be a Common Open Policy Server?
Wouldn't that entail also handling RSVP authorization?
Wouldn't it require configuring the access device for secure interaction
with this additional COPS server? How would this new COPS server
interact with the rest of the policy in the policy repository?
The mention of COPS does raise valid concerns about how the access
control policy of the PAA is coordinated with the rest of the policy.

Whether an existing (does MIDCOM count as existing) protocol can be
re-used is not the point; the PANA solution appears to require protocols
for each of these interactions. Each interaction must be specified.

It appears that there are at least these four (4) forms of communication
for which PANA must specify either a protocol or other mechanism.
Don't you think the requirements document should make this explicit?
These issues appear not yet resolved.

John

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 21 Feb 2002 09:11:00 -0500

John,

The two parts

  PAA -> DHCP server 

are out of the scope of PANA, since these are specific to access control.  
Perhaps it would be better to replace the word "PAA" in these two parts 
"The access control entity in the same node as the PAA."
And I don't think PANA must specify things that are out of scope.

I just tried to point out that multi-VLAN and interface switching can
be compatible if we could use appropriate access control mechanisms
together with PANA.

Yoshihiro Ohba

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Sat, 23 Feb 2002 15:28:39 -0800

John,

> Do you disagree with his proposal, or advocate this protocol?

Neither! :) Picking an ugly architecture which already has so many hacks to
make
existing protocols work and showing it won't get any nicer with PANA doesn't
make PANA any better or worse.

> a required behavior in all access devices. Is there consensus for that?

First we need to agree if the relay-agent approach is required. Only after
than we can talk about details of how this needs to be implemented.

> for each of these interactions. Each interaction must be specified.

John, I'm afraid you are asking architecture and deployment questions.. Not
PANA requirements related. If you can answer my original question, we can
better understand if we need anything new here: does PANA create any new
protocol requirement (or new requirements on other protocols) in this area?

> Don't you think the requirements document should make this explicit?

I don't. Framework document is a better place for them.

alper