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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 12 Feb 2002 12:02:00 +0100

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

=> This is what the solution needs to address.

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

=> IMO it doesn't and it doesn't need to. 
=> This is what the solution needs to address.

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

=> This is what the solution needs to address.

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

=> Other network layer protocols??? Is that an IETF issue??

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

=> How can you possibly maintain billing if 
you don't know the user identity????? Who's getting 
billed?? again the user 'as seen by the network'....

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

=> Yes. The WG assumes that there will be a solution.

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

=> The answer is in your assumption... Assuming
it's popular....vendors will have to support it.
QED.
It must be popular for a reason that justifies 
a transition period. 

Hesham