PaC with unspecified IP address

Requirements

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.

Current state

• PANA design to allow use of unspecified IP address– PaC by default will attempt IP configuration– Deployment decision whether network allows

an IP address configuration prior to PANA

Why allow unspecified PaC address?

• Security - attacks by unauthenticated clients– Address depletion attack (DHCPv4)– DAD-attack

• DHCP addresses

• IPv4 link-locals

• IPv6 link-locals - SEND can solve this

• Low-cost, directed, can be harder to detect

Why allow… (security)

• How does authenticating first, giving IP address later help?– In physically secured links: Client ID is known and

bound to the link after PANA. (when attack is detected, attacker can be identified)

– L2-ciphered prior to PANA: Attacker identification.– L2-ciphered after PANA: Attacker identification. – IPsec-based access control:

• Secure dhcp: draft-tschofenig-pana-bootstrap-rfc3118-00.txt

• Still need secure DAD… PANA SA might help SEND.. (a non-CGA-based scheme? For IPv4 too?)

• No straight forward benefit of configuring IP after PANA.

Utility of handling this threat

• Question: Does handling this DoS threat improve the overall security? [other DoS attacks]

Why allow… (deployment)• Deployment considerations

– In some scenarios, final address assignment depends on the client ID (authentication)

• Pre-PANA address, post-PANA address

– Allocation of pre-PANA address• IPv6: link-locals• IPv4:

– rely on IPv4 link-locals, or– Use (additional) local DHCP server

– Address management• If IPsec-based access control is used:

– Pre-PANA address is used even after PANA auth as the IPsec tunnel end-point

• If IPsec is NOT used, pre-PANA IPv4 address must be disabled after post-PANA address is obtained (IPv6 LL is OK)

Drawbacks…• Sending to unspecified IP address

– Use link-layer unicast and IP broadcast, or• not trivial• Used by Mobile IPv4 (FA never uses ARP for MN)

– Use link-layer and IP broadcast• Used by DHCP• Rely on a protocol field (PANA session ID)

• Receiving from unspecified IP address– Rely on link-layer address (not trivial), or– Rely on a protocol field (PANA session ID)

• Fragmentation– Not a requirement for EAP lower-layer, but for EAP methods

Question

• Do we want to (keep) allow(ing) use of unspecified IP addresses by PaCs?

• Do we want to assume Pac always has an IP address?