Subject: Re: Please review

From: Alper Yegin <[email-masked]>
Date: Tue, 13 May 2003 18:14:58 -0700

> 1)  This one might be a real nit. In the Introduction, the first para
> has four lines.
> 
>     Providing secure network access service requires access control
>     based on the authentication and authorization of the clients and
> the
>     access networks.
> 
>     Initial and subsequent client-to-network authentication provides
>     parameters that are needed to police the traffic flow through the
>     enforcement points.
> 
>     A protocol is needed to carry authentication methods between the
> client and 
>     the access network.
> 
> First line talks about authentication. Second line talks about the
> results of the authentication. Third line talks about the
> need for a protocol. And the second paragraph talks about the need
> for a link layer agnostic protocol. I am wondering something can
> be re-arranged here. I think after the second line above, the second
> paragraph can be merged e.g. "Currently, there are several link layer
> authentication protocols for providing secure network access....[rest
> mohanp> of the second para]
> 
>      IETF PANA Working Group has been chartered with the goal of
>       designing a network-layer access authentication protocol.
> 
> Do we really need this line ?

Hmm, I'll think about these. I'm not 100% sure we need these fixes.

> 
> 2) In section 4.1,
> 
> A PaC can be identified by the credentials (e.g., identifier,
> authenticator)
> 
>  This usage of the word identifier is confusing. It is not talking
> about device
>  identifier but about the identity of the device here. I think it
> would be better to use
>  identity to mean "authenticating the identity" and identifier to mean
> the "device
>  identifier".

I see. How about this:

PANA MUST enable authentication of  PaCs for network access. A PaC's
identity can be authenticated by verifying the credentials (e.g.,
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.

> 
> 3) In section 4.1,
> 
>  Both the PaC and the PAA MUST be able to authenticate each other for
>  network access. Providing capability of only PAA authenticating the
>  PaC is not sufficient.
> 
>  I guess the above the same issue we were discussing  yesterday i.e it
> depends
>  on which environment PANA is being used. So, you may need to clarify
> "MUST be able to".

New text added:

Both the PaC and the PAA MUST be able to authenticate each other for network
access. Providing capability of only PAA authenticating the PaC is not
sufficient. Mutual authentication capability is necessary in some
environments but not in all of them. For example, clients might not need to
authenticate the access network when physical security is available (e.g.,
dial-up networks).

> 
> 4) In section 4.1.4, identity and identifier can be used to clearly
> distinguish the
>  things that are used in authentication and authorization.

I didn't quite get what I should be doing here.

> 
> 5) In section 4.1.4,
> 
>      PAA MUST be able to create a binding between the PaC and the
>      associated DI upon successful PANA exchange. The DI MUST be
> carried
>      either explicitly as part of the PANA payload, or implicitly as
> the
>      source of the PANA message, or both.
> 
>  Isn't the second line related to the first line i.e The DI MUST be
> carried
>  for ...creating such a binding. It might help clarifying it.

Some new text here:

PAA MUST be able to create a binding between the PaC and the associated DI
upon successful PANA exchange. This can be achieved by PANA communicating
the PaC identifier and DI to the PAA during the protocol exchange. The DI
can be carried either explicitly as part of the PANA payload, or implicitly
as the source of the PANA message, or both.

Actually second and third sentences don't add much, but just for clarity...

> 
> 6) In section 4.2, I suggest we remove this sentence :
> 
> This threat may not be an issue for IPv6 because of the large
>      address space, but it can affect IPv4 networks.

If you can explain why we should remove it.... maybe we just need to fix it.

> 
> 7) In section 4.4,
> 
>  This transport is needed to create access
>  control lists to allow authenticated and authorized clients' traffic
> 
> 
> ^non-ascii
> 
>       This task is similar to what MIDCOM Working Group is trying to
>  achieve, therefore some of that WG's output might be useful here.
> 
>                                   ^ another non-ascii

ok.

> 8) In section 4.8, it is not clear what congestion control is referring
> to ?
>  It might be worth clarifying. Is it because the clients are just
> bombarding
>  PANA messages and causing congestion at the access router or
> somewhere
>  in the internet .. ? Does EAP over PPP/802.1x have this feature ? In
> IKE,
>  I have not seen this specifically.

I think what we are concerned is something like clients sending their
requests at the same time. This can happen when the power comes back up
after a shortage and the clients are somewhat synchronized. In the context
of PANA, this is concerned with the last hop, that is, the link between PaC
and PAA. 

Since the problem is similar for both, I suspect the solution would be
similar to router discovery's mechanisms for congestion-avoidance.

Maybe we can give some examples where congestion can occur:

   PANA MUST provide ordered-delivery for messages that carry EAP PDUs
   as described in [EAP].

   PANA MUST provide congestion control for the protocol messaging
   Under certain conditions PaCs might unintentionally get
    synchronized when sending their requests (e.g., upon recovering from a
   power outage on the access network). The network congestion generated
    from such events can be avoided by using techniques  like delayed
    initialization and exponential back off.

Thanks for the review.

Alper