Subject: [Pana] on PANA's requirement to use the unspecified address

From: Thomas Narten <[email-masked]>
Date: Fri, 07 Nov 2003 07:00:08 -0500

in looking at draft-ietf-pana-requirements-07.txt, it says:

> 4.2. IP Address Assignment 
>     
>    Assigning an IP address to the client is outside the scope of PANA. 
>    PANA protocol design MAY require the PaC to configure an IP address 
>    before using this protocol. Allocating IP addresses to 
>    unauthenticated PaCs may create security vulnerabilities, such as IP 
>    address depletion attacks on the access network [SECTHREAT]. 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. 
>     
>    This threat can be mitigated by allowing the protocol to run without 
>    an IP address configured on the PaC (i.e., using unspecified source 
>    address). Such a design choice might limit the re-use of existing 
>    security mechanisms, and impose additional implementation 
>    complexity. This trade off should be taken into consideration in 
>    designing PANA.

I'd like to better understand the above analysis and apparent
conclusion.

draft-ietf-pana-threats-eval-04.txt says:

>    6.5.1: There are various forms of DoS attacks that can be launched  
>    on the PAA or AS. A few are mentioned below. As it is hard to defend  
>    against some of the DoS attacks, the protocol should be designed  
>    carefully to mitigate or prevent such attacks.  
>   
>      . Attacker can bombard the PAA with lots of authentication  
>         requests. If PAA and AS are not collocated, PAA may have to  
>         allocate resources to store some state about PaC locally before  
>         it receives the response from the backend AS. This can deplete  
>         memory resources on PAA.  
>      . The attacker can force the PAA or AS to make computationally  
>         intensive operations with minimal effort, that can deplete the  
>         CPU resources of the PAA or AS.  
>      
>    T6.5.2: PaC acquires IP address before PANA authentication begins  
>    using methods like e.g., DHCP in IPv4 and auto-configuration in IPv6  
>    [PANAREQ]. If IP addresses are assigned before authentication, it  
>    opens up the possibility of DoS attack where malicious nodes can  
>    deplete the IP addresses by assigning multiple IP addresses. If  
>    stateless auto-configuration [ADDRCONF] is used, the attacker can  
>    respond to duplicate address detection probes sent by any node on the  
>    network effectively not allowing the node to configure a link local  
>    address. If stateful mechanism is used in IPv6 e.g., DHCPv6, then  
>    this attack is still possible. Address depletion attack is not  
>    specific to PANA, but a known attack in DHCP [DHCP-AUTH]. If PANA  
>    assumes that the client has an IP address already, it opens up the  
>    network to the DoS attack.  
>      
>    Requirement 9  
>      
>    PANA SHOULD not assume that the PaC has acquired an IP address before  
>    PANA begins.   

A couple of observations. Yes, DHC, stateless addrconf, and IPv4 LL
addressing are all vulnerable to DOS attacks that can prevent and
address from being assigned. But any PANA protocol will also be
subject to DOS attacks. E.g., it will almost certainly be possible to
interfere with ongoing PANA exchanges and cause DOS attacks that
prevent devices from obtaining service. So the conclusion that PANA
must also support a mode of operation in which addresses have not been
assigned does not (in mind) immediately follow. I.e, the case needs to
be made that:

a) the address depletion one is significant in the overall scheme  of
   things.
   
b) using the unspecified address would not leave the network
   vulnerable to other DOS attacks that make solving the previous one
   a waste of time. Note: folk might want to look at
   draft-ietf-vrrp-spec-v2-09.txt where they _removed_ security
   mechanisms after concluding they were useless due to bigger DOS
   issues related to IP's reliance on ARP.

Second, there are significant stack complications to allowing generic
communication with an unspecified address. Things to consider:

- IP fragmentation doesn't work reliably anymore (a recieving machine
  might think two fragments that are actually from two different
  machines are from the same machine, and reassemble them improperly).

- when sending to an unspecified address, the IP stack doens't know
  where to send the packet. Thus, special hacks (and API changes) are
  needed to specify the link-layer address (and interface) of where to
  send the packet.

- when receiving packets from the unspecified address (e.g. on the
  PAA), one needs a way of identifying which machine the packet came
  from. Normally, this would be the source IP address. But if that
  address is the unspecified address, we need something else. The two
  obvious choices are
  
    - use the sender's link-layer address. But note that now we aren't
      really using pure IP anymore (and we need stack/API support for
      this)...

    - add a field to the protocol itself that is used for this
      purpose. While that can be done with new protocols, it can't be
      done with existing protocols, so this approach is obviously not
      generally applicable where a goal is protocol reuse.

Given that there are costs (and significant ones IMO) associated with
using an unspecified address, I'm not convinced that the cost benefit
tradeoff has been evaluated correctly.

Thus, what I'd really like to understand is why the following isn't
the standard pana model:

- device gets an address using standard mechanisms (either DHC, IPv4
  LL, or IPv6 LL). Since the PAA is required to be on the same IP link
  as the PAC, LL addressing works just fine.

- Use the address obtained in the previous step to run PANA. Because
  its a proper address, IP-based protocols just work.

- Once PANA has completed, obtain a proper/better address, if that is
  what is needed. (And there are lots of ways of doing this, but that
  comes later).

Thomas

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: Soliman Hesham <[email-masked]>
Date: Sat, 8 Nov 2003 21:42:27 -0500

> Aside from the security issue, this approach has additional 
 > burden on the
 > deployment.
 > 
 > For the first step, either the PaC should be using an IPv4 link-local
 > implemantation, or the access network must be maintaining a 
 > DHCP pool of
 > temporary PANA addresses. The latter might mean having to 
 > add a DHCP server
 > on that network, which otherwise could be using a DHCP relay only.

=> Why not just provide a normal address (not LL and not 
a temp "special" DHC address for PANA)? The address could be 
provided with a short lease time if DoS is the issue. 
Do people know of current deployments that use HTTP
redirect and do not provide an IP address at the beginning?
We can have the same model in PANA. What happens if you
connect to the WLAN today, get an address and then never
login the HTTP redirect? This is certainly possible. 

 > 
 > For the third step, PANA should signal whether the current 
 > IP address can be
 > kept, and whether the PaC can (or has to) to obtain a new IP 
 > address. 

=> I wouldn't worry about that, I'd just provide the proper
address from the beginning. 

Hesham

---

From: Soliman Hesham <[email-masked]>
Date: Mon, 10 Nov 2003 11:30:20 -0500

> This doesn't help the networks where the address assignment 
 > depends on the
 > client's identity. In such networks, final address 
 > assignment must take
 > place after the client authentication.

=> Or: The IP address is assigned before authentication
and is communicated during the authentication. This could
then be used to open up the filters for that address/MAC
combination. The only argument against that is of course
the fear of DoS (address depletion). But as I said earlier
operators just don't seem to care about this, at least 
in the small deployments that I used. Perhaps others 
have different experiences? 

Hesham

PS: FWIW my cable modem  operator does exactly that, address
assignment first, then login. I've also seen it wherever
they have HTTP redirect used for authentication.

---

From: "MORAND Lionel FTRD/DAC/ISS" <[email-masked]>
Date: Tue, 11 Nov 2003 00:46:43 +0100

Hi Hesham, All,

>  > > => I wouldn't worry about that, I'd just provide the 
> proper  > > address from the beginning.  > 
> combination. The only argument against that is of course the 
> fear of DoS (address depletion). But as I said earlier 
> assignment first, then login. I've also seen it wherever they 
> have HTTP redirect used for authentication.

In the case of DSL networks, many scenarios require to authenticate the
user before the IP address assignment. This is to configure the
broadband access servers according to services subscribed by the user.
This configuration is performed by the network access provider. When PPP
is used, the configuration is based on information retrieved from the
physical layer (ATM link). In the broadband server, there is actually a
direct binding between the user, the ATM link and the PPP connection.

When your are considering a small/personal/residential LAN connected to
the Internet through a DSL access network, DHCP will be used. In that
case, the binding user/access link is broken at the broadband access
server level. A solution is then needed to authenticate the user. If
HTTP redirect may be used when the user just wants to access to the
Internet in early deployments (few requirements in terms of access
configuration), this solution is not acceptable when you are thinking
about the deployment of advanced service architectures on a large scale.

By the way, when the DHCP server is located behind the brodband access
server (belonging to the service provider) and you want to control any
flow being sent over the access operator's IP backbone, you need to
authenticate the user before any IP address allocation. If you refer to
the mobile world, a user must be authenticated before requesting an IP
address (using DHCP) through the GRX backbone (GRX is the private IP
backbone interconnecting the mobile operator networks). This user
authentication is also used to configure the access server according to
subscribed services.

So, from my point of view, there is indeed a need for supporting user
authentication before any IP address allocation.

Best regards,

Lionel

---

From: "MORAND Lionel FTRD/DAC/ISS" <[email-masked]>
Date: Tue, 11 Nov 2003 00:46:43 +0100

Hi Hesham, All,

Best regards,

Lionel

---

From: Soliman Hesham <[email-masked]>
Date: Tue, 11 Nov 2003 05:14:27 -0500

> This email is in response to Hesham's suggestion about assigning IP
 > address before authentication phase:
 > 
 > A typical NAS deployed in a large network usually serves multiple
 > "Internet Service Providers" and "Application Service 
 > Providers". Every
 > ISP owns a collection of IP address pools. Each collection is usually
 > referred to as a "domain".  A number of ISP's may use a 
 > single address
 > space and hence a single routing context. Some NAS's support multiple
 > routing contexts in the same physical device to allow the use of
 > overlapping address spaces by multiple ISPs. (See the last paragraph
 > about Application Service Providers).
 > 
 > So, it is important for the NAS device to find out which ISP 
 > to allocate
 > the IP address from. 

=> Agreed. I also agree that this is a typical wholesale/retail
split scenario where the wholesaler would want to use 
the right address pool for the retailer and therefore
needs to know the client's id first. There is no dispute
with the scenario itself, the question is whether PANA
should be designed to do that as a default behaviour. 

If a certain optimisation requires that we require auth
before address allocation then it can be added to the 
base PANA. But having that as a default behaviour
introduces its own set of (significant) problems. 

The models you refer to do not use an upper layer auth
protocol (please correct me if I'm wrong here). The 
only ones that do (I've cited a couple) allocate addresses
first then authenticate. Why? because as Alper said "they
don't have a choice". I wonder whether we could "magically"
provide that choice, i.e. there is a cost involved. 

Hesham 

   For PPP users, this is done by looking 
 > at the FQDN
 > and associating the domain-part of it to an ISP.
 > 
 > DHCP based access does not have this concept. It is primarily for
 > host-configuration in a single routing context. All the 
 > hosts on a given
 > interface must use a single ISP (and hence a single routing 
 > context), if
 > they use DHCP.  Cable modem operators own the NAS device as well as
 > function as the only ISP. However, there are also wholesale models in
 > which the NAS device is owned by one entity and the Internet 
 > Service is
 > provided by multiple ISP's sharing the same NAS.
 > 
 > If there is a single NAS and a single ISP, 
 > address-depletion-based DoS
 > attack is equivalent to having a wrong-password.  If there 
 > are multiple
 > ISPs, the problem is more fundamental than that - NAS does not know
 > which address to choose. In addition, this choice has to be dynamic
 > (i.e. not statically configured) depending on the user's identity.
 > 
 > Extending the host-configuration a bit beyond IP address 
 > assignment, the
 > host should be configured depending on the user. A person usually
 > connects to a domain creating a login-session. The domain 
 > has IP address
 > pools, DNS servers, WINS servers, DHCP servers, email-server,
 > access-control-lists, firewall rules etc. etc. and these 
 > parameters are
 > specific to domains. NAS needs a way of figuring out the 
 > services to be
 > offered to a user and it uses FQDN today. To offer the services
 > successfully, host-configuration must be done after NAS 
 > performs a AAA
 > procedure.
 > 
 > - prakash
 > 
 > 
 > >
 > > Hesham
 > >

---

From: Soliman Hesham <[email-masked]>
Date: Tue, 11 Nov 2003 05:14:27 -0500

Hesham