Subject: RE: Please review

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 14 May 2003 09:25:47 -0700

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

Sounds good to me.

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

The last sentence can be reworded to "It may not be sufficient
for just the PAA to authenticate the PaC" (or something better). 

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

ok.

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

Same as (2) above. During the authentication phase, you verify
the identity of some one. This is the most common usage. And
access control is based on identifier/device identifier. I am
mostly biased by IKE/Ipsec usage.

> 
> > 
> > 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.
> 
That sounds better.

> 
> 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.
> 
It provides a wrong idea that this threat need not be
addressed for IPv6. It is just not the address alone that
is being depleted, but CPU,network, memory resources.

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

Okay, the word synchronized helps capture it better.

-mohan

> Thanks for the review.
> Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 14 May 2003 11:16:08 -0700

> is being depleted, but CPU,network, memory resources.

   Providing address assignment functionality is outside the scope of
   PANA. PANA protocol design MAY require the PaC to configure an IP
   address before using this protocol. Allocating an IP address to
   unauthenticated PaCs may create security vulnerabilities, such as IP
   address depletion attacks on the access network [SECTHREAT]. This
   threat may not be an issue for IPv6 because of the large address
   space, but it can affect IPv4 networks.

Yes, even if we have infinitely many IP addresses, IP address allocation
process costs other resources. In the case of IPv4, though, the most
important resource to be consumed is the IP address space. So this is why it
takes the center attention.

We can say this instead of the last sentence above:

  IPv4 networks with limited address space are the main targets of such
  attacks. Launching a successful attack that can deplete the addresses in
  an IPv6 network is relatively harder.

Alper