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-rfc 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?