PANA Framework

Prakash Jayaraman, Rafa Marin Lopez, Yoshihiro Ohba, Mohan Parthasarathy, Alper Yegin

IETF 59

IETF 59

FrameworkFunctional modelSignaling flowDeployment environmentsIP address configurationData traffic protectionProvisioningNetwork selectionAuthentication method choiceDSL deploymentWLAN deployment

IETF 59

Functional Model

RADIUS/ Diameter/ +-----+ PANA +-----+ LDAP/ API +-----+ | PaC || PAA || AS | +-----+ +-----+ +-----+ ^ ^ | | | +-----+ | IKE/ +-------->| EP |

Signaling Flow PaC EP PAA AS | PANA | | AAA | ||| | | | | | | SNMP | | | || | | Sec.Assoc. | | | || | | | | | | | Data traffic | | | | | | | | | |

IETF 59

Deployment Environments(a) Networks where a secure channel is already available prior to running PANA(a.1) Physical security. E.g.: DSL(a.2) Cryptographic security. E.g.: cdma2000

(b) Networks where a secure channel is created after running PANA(b.1) Link-layer per-packet security. E.g.: Using WPA-PSK.(b.2) Network-layer per-packet security. E.g.: Using IPsec.

IETF 59

IP Address Configuration Pre-PANA address: PRPAConfigured before PANA

Post-PANA address: POPAConfigured after PANA when:IPsec is used, orPRPA is link-local or temporaryPAA informs PaC if POPA needed

IETF 59

PRPA ConfigurationPossible ways:StaticDHCPv4 (global, or private address)IPv4 link-localDHCPv6IPv6 address autoconfiguration (global, or link-local)

IETF 59

POPA Configuration (no IPsec)DHCPv4/v6IPv4:POPA replaces PRPA (prevent address selection problem)Host route between PaC and PAA (preserve on-link communication)IPv6: use both PRPA and POPA at the same time

IETF 59

POPA Configuration (IPsec)Possible ways:IKEv2 configurationDHCP configuration of IPsec tunnel mode (RFC 3456)PRPA used as tunnel outer address, POPA as tunnel inner address

IETF 59

CombinationsTOATIA

IETF 59

Additional Approaches: (1)Using a PRPA as TIAIPv6:Configure a link-local and global before PANA (DHCPv6 or stateless)TIA=global, TOA=link-localRequires SPD selection based on the name (session-ID), not the IP addressExplicit support in RFC2401bisName is set, address selectors are NULLRFC2401? Not clear.Racoons generate_policy directive Authenticate peer by PSK, accept proposed TIA (skip SPD check), than create SPD Should we include this?

IETF 59

Additional Approaches: (2)Using a PRPA as TIAIPv4:Configure a global address before PANA (static, or DHCPv4)TIA=TOA=PRPARFC2401: Same considerations.Forwarding considerations:Requires special handling on EP, or else:tunnel_to PRPA(tunnel to PRPA(tunnel to PRPA(to PRPA)))... FreeSwan handles this. Others?Should we include this?

IETF 59

Data Traffic ProtectionAlready available in type (a) environmentsEnabled by PANA in type (b) environmentsEAP generated keysSecure association protocoldraft-ietf-pana-ipsec-02

IETF 59

PAA-EP Provisioning ProtocolEP is the closest IP-capable access device to PaCsCo-located with PAA or separatedraft-yacine-pana-snmp-01Carries IP or L2 address, optionally cryptographic keysOne or more EPs per PAAEP may detect presence of PaC and trigger PANA by notifying PAA

IETF 59

Network (ISP) Discovery and SelectionTraditional selection:NAI-basedPort number or L2 address based

PANA-based discovery and selection:PAA advertises ISPsPaC explicitly picks one

IETF 59

Authentication Method ChoiceDepends on the environment

IETF 59

DSL

Host--+ +-------- ISP1 | DSL link | +----- CPE ---------------- NAS ----+-------- ISP2 | (Bridge/NAPT/Router) | Host--+ +-------- ISP3

premisePANA needed when static IP or DHCP-based configuration is used (instead of PPP*)

IETF 59

DSL DeploymentsBridging mode:

Host--+ (PaC) | +----- CPE ---------------- NAS ------------- ISP | (Bridge) (PAA,EP,AR) Host--+ (PaC)

Address Translation (NAPT) Mode:

Host--+ | +----- CPE ---------------- NAS ------------- ISP | (NAPT, PaC) (PAA,EP,AR Host--+

IETF 59

DSL DeploymentRouter mode:

Host--+ | +----- CPE ---------------- NAS ------------- ISP | (Router,PaC) (PAA,EP,AR) Host--+

IETF 59

Dynamic ISP SelectionAs part of DHCP protocol or an attribute of DSL access lineDHCP client idRun DHCP, and PANAPRPA is the ultimate IP address (no POPA)

As part of PANA authenticationTemporary PRPA via zeroconf or DHCP with NAPRun PANA for AAAPOPA via DHCP, replace PRPA

IETF 59

WLANNetwork-layer per-packet security (IPsec):EP and PAA on access router

Link-layer per-packet security (WPA-PSK):EP is on access point, PAA is on access router

IETF 59

IPsec, IKEv2 PaC AP DHCPv4 Server PAA EP(AR) | Link-layer | | | | | association| | | | || | | | | | | | | | DHCPv4 | | | || | | | | | | | |PANA(Discovery and initial handshake phase | | & PAR-PAN exchange in authentication phase) | || | | | | | | | |Authorization| | | |[IKE-PSK, | | | | PaC-DI, | | | | Session-Id] | | | |------------>| | | | | |PANA(PBR-PBA exchange in authentication phase) | || | | | | | | | IKE | | | (with Configuration Payload exchange or equivalent) | || | | | | | | | |

IPv4:IPsec-TOA=PRPA (dhcp)IPsec-TIA=POPA (IKE)Alternative: RFC 3456IPv6:IPsec-TOA= PRPA (link-local)IPsec-TIA= POPA (IKE)

IETF 59

Bootstrapping WPA/IEEE 802.11iPre-shared key mode (PSK) enabledMAC address is used as DIEP is on access pointProvides:Centralized AAAProtected disconnectionNo changes to WPA or IEEE 802.11i required

IETF 59

Flow +------------------+ | Physical AP | | +--------------+ | | |Virtual AP1 | | Unauth | |(open-access) |---- VLAN\ | | | | \+-------+ +---+ | +--------------+ | |PAA/AR/| |PaC| ~~~~ | | |DHCP | +---+ | +--------------+ | |Server | | |Virtual AP2 | | /+-------+ | |(WPA PSK mode)|---- Auth / | | | | | VLAN | | +--------------+ | | | | | +------------------+ Internet 1- Associate with unauthenticated VLAN AP2- Configure PRPA via DHCP or link-local3- Perform PANA and generate PMK4- Associate with authenticated VLAN AP, perform 4-way handshake, generate PTK5- Obtain new IP address

IETF 59

Co-located PAA and AP(EP)Does not require virtual AP switchingPANA, DHCP, ARP, ND traffic allowed on the 802.1X uncontrolled port

IETF 59

Capability DiscoveryTypes of networks:IEEE 802.1X-securedLook at RSN information element in beacon framesPANA-securedData driven PANA discoveryClient initiated discoveryUnauthenticated (free)

IETF 59

The End

IETF 59

Should this I-D become a PANA WG item?

IETF 59

IPsec, DHCP PaC AP DHCPv4 Server PAA EP(AR) | Link-layer | | | | | association| | | | || | | | | | | | | | DHCPv4 | | | || | | | | | | | |PANA(Discovery and Initial Handshake phase | | & PAR-PAN exchange in Authentication phase) | || | | | | | | | | | |Authorization| | | | |[IKE-PSK, | | | | | PaC-DI, | | | | | Session-Id] | | | | |------------>| | | | | | |PANA(PBR-PBA exchange in Authentication phase) | || | | | | | | | | IKE | | || | | | | | | | | | |

IPv4:IPsec-TIA= IPsec-TOA= PRPA (dhcp)IPv6:IPsec-TOA= PRPA (link-local)IPsec-TIA= POPA (dhcp)IPv6 can also use stateless address autoconf.

IETF 59