; PaC with unspecified IP address
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

PaC with unspecified IP address

VIEWS: 0 PAGES: 9

  • pg 1
									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?

								
To top