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: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 7 Nov 2003 14:10:55 -0800

Thomas,

> I'd like to better understand the above analysis and apparent
At one of the IETF meeting,  we discussed about this particular case.
The conclusion is to look at the trade-offs of using an unspecified
address. As you note below there are some additional complexities.
At least the issue of fragmentation did surface in some private
discussions. More below.

> assigned does not (in mind) immediately follow. I.e, the case needs to
It is a "SHOULD" above. Perhaps you are saying that it should be a "MAY" ?

>    issues related to IP's reliance on ARP.
The basic idea is to see whether it is possible to mitigate against
address depletion attack assuming there are good tradeoffs. I am
not sure why this DoS attack needs special treatment compared
to other DoS attacks.

>   machines are from the same machine, and reassemble them improperly).
Agreed. Some stacks maintain the reassembly queue per interface which solves
problem with link-local addresses in general. But for unspecified address,
unless mac addresses are used (which may not be reasonable), the problem
will exist.

>   needed to specify the link-layer address (and interface) of where to
As DAD has been there for sometime, i thought most of the stacks
should be supporting this API.

>   address is the unspecified address, we need something else. The two
Agreed. But with mobile IPv4 similar problem existed where FA cannot
ARP for MN where you needed to know the source MAC address
of the MN.  Agreed that this may not be a standard API.

> tradeoff has been evaluated correctly.
I agree to some extent. Are you concerned about the wording in the
draft ? The PANA requirements draft itself  does not say anything
strong about this. I agreed that the threats draft can include a
better analysis on this part to point out the tradeoffs.

>   as the PAC, LL addressing works just fine.
Some stacks typically use a single global queue for reassembly. If the
same mac addresses are used  for src and dst on two different links,
such problem would still exist.  Not sure whether this is a common
problem or not.

>   its a proper address, IP-based protocols just work.
Sure. I  have not read the latest version of the PANA protocol document.
I don't know how much of this directly affects the functioning of the
protocol itself. Sure some of the implementation complexities might
still be there.

As i mentioned earlier, the requirements document itself does not
prohibit from using link local addresses. Perhaps the threats document
should be fixed.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 7 Nov 2003 14:10:55 -0800

Thomas,

-mohan

---

From: Alper Yegin <[email-masked]>
Date: Sat, 08 Nov 2003 15:46:05 -0800

...

> prevent devices from obtaining service.

We need to look at the specifics of this DoS attack. Why does this DAD-based
attack deserves prevention? Because it is very easy to launch (low cost), an
ongoing attack might not be detectable, it does not have to be network-wide
(i.e., it can be directed at a targeted victim), and it can be relatively
easily mitigated.

> So the conclusion that PANA

Yes, when unspecified IP address is used, IP-layer fragmentation should not
be used for PANA. But note that, fragmentation is a requirement on the EAP
methods, not the EAP lower layers anyways. IP-layer fragmentation can be
used as a bonus of PANA when PaC has an IP address, and not otherwise.

> needed to specify the link-layer address (and interface) of where to

Either that, or a broadcast destination should be used. This dual approach
is used by DHCP. On the other hand, Mobile IPv4 relies on the special hacks.

>     generally applicable where a goal is protocol reuse.

We can use PANA session ID for this purpose (which is already defined for
other reasons). So, when the special hack is not available, the
implementation can rely on this field for matching the PANA packets with the
clients. [btw, I'm not sure why we need to consider "existing protocols"]

> what is needed. (And there are lots of ways of doing this, but that

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.

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. This
shouldn't be hard to encode in the PANA design.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Sat, 08 Nov 2003 15:46:05 -0800

...

Alper

---

From: Thomas Narten <[email-masked]>
Date: Tue, 11 Nov 2003 09:17:28 -0600

> It is a "SHOULD" above. Perhaps you are saying that it should be a
  "MAY" ?

What I'd prefer, is that it not be even a MAY. I.e, just drop this
completely. The basic problem here is that we are talking about a
capability that the PANA protocol would need to support, even if it is
only a MAY. It's like being a little pregnant. If there is a need
(however rare in practice) that the unspecified address needs to be
used, the PANA protocol has to include this and implementations will
need to support it. So you have to deal with all the ramifications in
the PANA protocol.

> not sure why this DoS attack needs special treatment compared

Yep. That is what I'm trying to understand.

> unless mac addresses are used (which may not be reasonable), the problem

It is not reasonable, IMO, because this is a change to the IP stack
itself. Not in the scope of PANA to require.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Tue, 11 Nov 2003 09:17:28 -0600

Thomas