110 likes | 256 Views
PANA Network Selection draft-ohba-pana-netsel-00.txt. Yoshihiro Ohba. Background. Network selection was defined older revisions of PANA specification to provide following functions NAP and ISP separate authentication ISP selection
E N D
PANA Network Selectiondraft-ohba-pana-netsel-00.txt Yoshihiro Ohba IETF70 PANA WG
Background • Network selection was defined older revisions of PANA specification to provide following functions • NAP and ISP separate authentication • ISP selection • During IETF last call, network selection was removed from PANA specification, with suggestion to define it in a separate document • This draft is submitted as such a document IETF70 PANA WG
A new bit in PANA Header for NETSEL 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R S C A P I N r r r r r r r r r| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • N(Network Selection) This bit is set when the sender supports network selection function IETF70 PANA WG
‘N’ bit Usage • The PAA andPaC advertise their support for the network selection function in theinitial PAR and PAN messages with both 'S’ (Start) and ‘N’ (Network selection) bits set. • If 'N' bit is set in both messages, the PAA andPaC may start NAP and ISP Separate Authentication and/or ISP selection IETF70 PANA WG
NAP and ISP Separate Authentication • Two PANA sessions are established between the PaC and PAA, one for NAPauthentication and the other for ISP authentication. • For the PANA session used for NAP authentication, PAR message sent in response to the initial PAR-PAN exchange with 'S' (Start) bit set carries one NAP-Information AVP. • The PANA session used for ISP authentication MUST NOT carry a NAP-InformationAVP. • When a PANA SA is established, the same NAP-Information AVPMUST be carried in the last PANA-Auth-Request message with 'C' (Complete) bit set with an AUTH AVP • Issue: PANA SA should be a MUST considering crypto binding (see below) • When NAP and ISP separate authentication is performed, cryptographicbinding MUST be made between the two session • How the cryptographic binding is created is TBD IETF70 PANA WG
ISP Selection • ISP selection MUST NOT be performed over a session used for NAP authentication. • ISP selection MAY be performed in the absence of NAP and ISP separate authentication • The second PAR message (with ‘S’ bit cleared) with ‘N’ bit set carries one or more ISP-Information AVPs • When there is only one ISP-Information AVP, there is only one ISP choice • The PAN message sent in response to this PAR message carries at most one ISP-Information AVP to indicate the ISP chosen by the PaC. • In the absence of an ISP in the PAN, ISP selection is typically performed based on the client identifier(e.g., using the realm portion of an NAI carried in EAP method). • When a PANA SA is established, the ISP-Information AVP for the selected ISP MUST be carried in the last PAR message with 'C' (Complete) bit set with an AUTH AVP IETF70 PANA WG
Example Call Flow(NAP Authentication) PAA PaC PCI PSR[S=N=1]{Algorithm} PSA[S=N=1]{Algorithm} PSR[N=1]{NAP-Information<NAP1>, EAP-Payload} PSA[N=1]{EAP-Payload} PSR[N=1]{EAP-Payload} PSA[N=1]{EAP-Payload} : PAR[C=N=1]{NAP-Information<NAP1>, EAP-Payload, Key-ID, AUTH} PAN[C=N=1]{Key-ID, AUTH} IETF70 PANA WG
Example Call Flow(ISP Selection w/ one ISP choice) PAA PaC PCI PSR[S=N=1]{Algorithm} PSA[S=N=1]{Algorithm} PSR[N=1]{ISP-Information<ISP1>, EAP-Payload} PSA[N=1]{EAP-Payload} PSR[N=1]{EAP-Payload} PSA[N=1]{EAP-Payload} : PAR[C=N=1]{ISP-Information<ISP1>, EAP-Payload, Key-ID, AUTH} PAN[C=N=1]{Key-ID, AUTH} IETF70 PANA WG
Example Call Flow(ISP Selection w/ two ISP choices) PAA PaC PCI PSR[S=N=1,SID=y]{Algorithm} PSA[S=N=1,SID=y]{Algorithm} PSR[N=1]{ISP-Information<ISP1>, ISP-Information<ISP2>, EAP-Payload} PSA[N=1]{ISP-Information<ISP1>,EAP-Payload} PSR[N=1]{EAP-Payload} PSA[N=1]{EAP-Payload} : PAR[C=N=1]{ISP-Information<ISP1>, EAP-Payload, Key-ID, AUTH} PAN[C=N=1]{Key-ID, AUTH} IETF70 PANA WG
NAP-Information AVPISP-Information AVP • {NAP,ISP}-Information AVP is of type Octet-String that carries an {NAP,ISP} name encoded as a RADIUS Operator-Name attribute value [I-D.ietf-geopriv-radius-lo] (see below) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Namespace ID | Operator-Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Operator-Name ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Namespace ID = ‘0’ (TADIG in GSM), ‘1’ (REALM), ‘2’ (E212), ‘3’ (ICC) IETF70 PANA WG
Thank You! IETF70 PANA WG