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

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 07 Nov 2003 14:21:17 -0800

Please find "<Ohba: ....>" for my comments.

To: [email-masked]
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
List-help: <mailto:[email-masked]?subject=help>
List-id: Protocol for carrying Authentication for Network Access
<pana.ietf.org>
List-post: <mailto:[email-masked]>
List-subscribe:
<https://www1.ietf.org/mailman/listinfo/pana>,<mailto:[email-masked]?
subject=subscribe>
List-unsubscribe:
<https://www1.ietf.org/mailman/listinfo/pana>,<mailto:[email-masked]?
subject=unsubscribe>
Sender: [email-masked]

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.

<Ohba: First, this attack is not significant in IPv6 when SEND is used for
protecting neighbor discovery. So we might focus on IPv4 for this issue. In
IPv4, I think the answer depends on whether link-layer is secured over
multi-access link or not. If link-layer of multi-access link is not secured,
the address depletion attack might not be significant because MAC address
spoofing can easily interfare with ongoing PANA exchange regardless of
whether the client uses unspecified IP address or not.  If the link-layer is
secured enough to prevent MAC address spoofing, PANA with unspecified IP
address could improve robustness of PANA itself in that PANA signaling in
this case does not have to perform address duplication check. DoS attack to
PANA signaling could be mitigated in this case since link-layer frame with
spoofed MAC address will be filtered out by the link-layer.>

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.

<Ohba: I think this also depends on the security of link-layer of
multi-access link. If the link-layer is secured to prevent MAC address
spoofing, it is also possible to mitigate ARP spoofing by checking the
hardware address carried in ARP message payload against the one carried in
the link-layer header which is secured.>

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

<Ohba: Yes.  So PANA will need to rely on EAP-layer fragmentation (i.e.,
fragmentation by EAP methods) when an unspecified address is used.>

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

<Ohba: Yes. PANA implementation in Open Diameter project does this hack.
Especially Windows PANA implementation needs some driver to obtain
link-layer address from link-layer headers. This makes PANA implementation
difficult to be implemented by using OS-independent programming language
such as Java.>

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

<Ohba: PANA implementation in Open Diameter project takes this approach.>

    - 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

<Ohba: In IPv6 there is no problem with the above model if SEND is used for
protecting neighbor discovery. I think the cost-benefit tradeoff depends on
the importance level of the scenario where IPv4 PANA is performed over
secured multi-access link.>

Yoshihiro Ohba

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