Transcript PaC with unspecified IP address

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