submission doc.: ieee 11-12/0273r9 may 2012 hiroki nakano, trans new technology, inc.slide 1 sfd...

Submission

doc.: IEEE 11-12/0273r9May 2012

Hiroki Nakano, Trans New Technology, Inc.Slide 1

SFD Text for Upper LayersDate: 2012-05-14

Authors:Name Affiliations Address Phone email

Hiroki Nakano Trans New Technology, Inc.

Sumitomo Seimei Kyoto Bldg. 8F,62 Tukiboko-cho, Shimogyo,Kyoto 600-8492 JAPAN

+81-75-213-1200

[email protected]

Hitoshi Morioka

Allied Telesis R&D Center

2-14-38 Tenjin, Chuo-ku Fukuoka 810-0001 JAPAN

+81-92-771-7630

[email protected]

Submission

doc.: IEEE 11-12/0273r9

Hiroki Nakano, Trans New Technology, Inc.

Abstract

DCN: IEEE11-12/0273r9

Title: SFD Text for Higher Layers

Authors and Companies:

Hiroki Nakano (Trans New Technology, Inc.)

Hitoshi Morioka (Allied Telesis R&D Center)

Scope: Upper layer

Motivation: page 3 (abstract)

Background information: page 4-31

Motion: page 32-39 including five motions

Slide 2

May 2012

Submission

doc.: IEEE 11-12/0273r9May 2012


Slide 3

Motivation

• An IP(v4) address are normally assigned by DHCP(v4) and the specification of DHCP is stable. DHCP includes definition of state transition and have lots of extensions derived from lots of past discussions. Non-AP STA should be still a DHCP client.

• The discussions of IPv6 address assignment are still going on actively in IETF and its specification is being changed. We should provide a framework for them.

• In addition, TGai should not deny the other protocols because we are the link layer.

Submission

doc.: IEEE 11-12/0273r9


Background Information for IPv4

RFC2131 - Dynamic Host Configuration Protocol

RFC4039 - Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)

Slide 4

May 2012

Submission

doc.: IEEE 11-12/0273r9


Background Information for IPv6

RFC3315 - Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

RFC4429 - Optimistic Duplicate Address Detection (DAD) for IPv6

RFC4862 - IPv6 Stateless Address Autoconfiguration

RFC6106 - IPv6 Router Advertisement Options for DNS Configuration

RFC6434 - IPv6 Node Requirements

Slide 5

May 2012

Submission

doc.: IEEE 11-12/0273r9May 2012


The past Straw poll 1

Do you support to add the following text to the clause 4 of SFD:

“The TGai amendment defines a method of IP(v4) address assignment which works as a transport of DHCP.”

Yes: 5 No: 3 Don’t care: 17(Mar 15 AM1)

Submission

doc.: IEEE 11-12/0273r9May 2012


The past Straw poll 2

Do you support to add the following text to the clause 4 of SFD:

“The TGai amendment defines a generalized method for upper layer transport encapsulation during FILS to enable higher layer services.”

Yes: 7 No: 1 Don’t care: 22(Mar 15 AM1)

Submission

doc.: IEEE 11-12/0273r9May 2012


Proposed Amendment 1

Clause to amend: Section 3

Add to the last of Section 3:

3.x Encapsulation Framework for HLCF

The TGai amendment defines a generalized method for upper layer transport encapsulation during FILS to enable higher layer services.

Submission

doc.: IEEE 11-12/0273r9May 2012


Motivation of Proposed Amendment 1

• This sentence intends TGai to support IPv4, IPv6 and other upper layer protocols.

• Transparency as a link layer is important in order to support various upper layer protocols.

Submission

doc.: IEEE 11-12/0273r9


Possibly Encrypted

Generalized Sequence

May 2012

Slide 10

Non-AP STA AP Conf. server

Hig

her

Lay

er C

onfi

gura

tion

Ser

vice

Processing for security

Configuration Request

Configuration Reply

AS

At this point, Non-AP STA has been authenticated.

AP keeps a HLCF data. Maximum time is assumed to be less than 100 msec.

less

than

100

ms

(See

TG

ai F

unct

iona

l Req

uire

men

ts)

PossiblyEncrypted

AS and Conf. server can reside inside AP.

Submission

doc.: IEEE 11-12/0273r9May 2012




Add the following text:

5.x Forwarding of HLCF information

The TGai amendment defines HLCF as an AP forwards information carried from an non-AP STA by HLCF to the others than the non-AP STA only either after successful authentication or with assurances of the same security level as the existing 802.11 security framework.

Submission

doc.: IEEE 11-12/0273r9


Possibly Encrypted

Sequence Example by DHCP with RCO

May 2012

Slide 12

Non-AP STA AP DHCP server

DH

CP

Cli

ent S

oftw

are


DHCP Discover w/ RCO

DHCP Ack

AS


AP keeps a DHCP packet. Maximum time is assumed to be less than 100 msec.

less

than

100

ms

(See

TG

ai F

unct

iona

l Req

uire

men

ts)

PossiblyEncrypted

Submission

doc.: IEEE 11-12/0273r9


Possibly Encrypted

Sequence Example by ICMPv6 RS/RA

May 2012

Slide 13

Non-AP STA AP Router

Sta

tele

ss C

onfi

gura

tion

Sof

twar

e


Router Solicitation

Router Advertisement

AS


AP keeps a RS packet. Maximum time is assumed to be less than 100 msec.

less

than

100

ms

(See

TG

ai F

unct

iona

l Req

uire

men

ts)

PossiblyEncrypted

Submission

doc.: IEEE 11-12/0273r9


Possibly Encrypted

Sequence Example by DHCPv6

May 2012

Slide 14

Non-AP STA AP Router

Sta

tefu

l Con

figu

rati

on S

oftw

are


Router Solicitation

ICMPv6 RA with M flag

AS


AP keeps a RS packet. Maximum time is assumed to be less than 100 msec.

less

than

100

ms

(See

TG

ai F

unct

iona

l Req

uire

men

ts)

PossiblyEncrypted

DHCPv6 on 802.11 Data frames

Submission

doc.: IEEE 11-12/0273r9


Sequence Example by DHCPv6 with RCO(challenging framework)

May 2012

Slide 15


Sta

tefu

l Con

figu

rati

on S

oftw

are


DHCPv6 Solicit w/ RCO

RA & DHCPv6 Reply

AS


AP keeps a DHCP packet. Maximum time is assumed to be less than 100 msec.

less

than

100

ms

(See

TG

ai F

unct

iona

l Req

uire

men

ts)

PossiblyEncrypted

Possibly Encrypted

Submission

doc.: IEEE 11-12/0273r9


Comments & Answers

• Frames get bigger. It’s the problem.• TGai intends to reduce exchanges of packets, not reduce

information itself. Therefore, it is natural that less exchanges leads to bigger packets. A round trip of 1000-byte-long frames is obviously preferable to 10 round trips of 100-byte-length packets.

• TGai can provide special “compression” encodings for specific upper layer protocols, such as DHCP. For instance, most of DHCP packets have about 200-byte-long consecutive zeros and a generic data compression technique or a special encoding for DHCP can compress DHCP packets without changing information.

Slide 16

May 2012

Submission

doc.: IEEE 11-12/0273r9


Comments & Answers

• What packets should be forwarded or not? Does it affect security?• Basically, piggybacked frames of upper layers should be

forwarded after authentication is finished. Essentially, non-AP STA can throw any kind of packets for upper layers after authentication.

• If you want a further optimization such as a premature start of IP address assignment processing before completion of authentication, you must consider security mechanism such as packet filtering. However, this is out of our scope, although TGai does not prevent such techniques.

Slide 17

May 2012

Submission

doc.: IEEE 11-12/0273r9


Comments & Answers

• How long does an AP wait for a response from DHCP server?• The TGai Functional Requirements document requests to provide

a secure link set-up in less than 100 ms.

• Therefore, Maximum time for an AP to wait is 100ms.

• DHCP packets transfer between an AP and a non-AP STA in a normal manner after 802.11ai link setup. If a response from DHCP server reaches an AP after the AP sends a response to non-AP STA, DHCP packets can be sent in the same manner as Data frames.

Slide 18

May 2012

Submission

doc.: IEEE 11-12/0273r9


Possibly Encrypted

A Case with late Reply from Conf. server

May 2012

Slide 19

Non-AP STA AP Conf. server

Hig

her

Lay

er C

onfi

gura

tion

Ser

vice


Configuration Request

Configuration Reply

AS

AP can abandon piggybacking after waiting for configured period.

less

than

100

ms

(See

TG

ai F

unct

iona

l Req

uire

men

ts)

PossiblyEncrypted

Normal data frame

Association Response

Submission

doc.: IEEE 11-12/0273r9


Comments & Answers

• What happens when lease time of an IP address is expired?• Higher layer protocols can use normal data frames to exchange

additional packets for DHCP etc. Extension of DHCP lease time will be done in a normal manner.

Slide 20

May 2012

Submission

doc.: IEEE 11-12/0273r9


Comments & Answers

• Do APs require to keep HLCF (DHCP) packets during processing for security? Does this enable attackers to consume memory of APs?• TGai assumes that each authentication for each non-AP STA is

finished within 100ms. See Section 2.2.1 “Link Set-Up Time” of TGai Functional Requirements (IEEE 11-11/0745r5)

• Our media 802.11 can transfer 5000 packets per second at most.

• The size of a HLCF packet is 1500 byte at most.• MTU of 802.11 is about 2300 byte.

• Therefore, amount of packets for AP to keep is 750KB at most in case that all packets flying are employed for attacks.

Slide 21

May 2012

Submission

doc.: IEEE 11-12/0273r9


Comments & Answers

• IPv6 has the DAD (Duplicate Address Detection) mechanism. Does this take a long time?• RFC4429 defines Optimistic Duplicate Address Detection (DAD)

for IPv6. This mechanism enables us to use IPv6 address before DAD is finished, while DAD is being performed by using normal 802.11 data frames.

Slide 22

May 2012

Submission

doc.: IEEE 11-12/0273r9


Comments & Answers

• Is SEcure Neighbor Discovery (RFC3971) available on this framework?• Router Solicitation with the unspecified address can be used.

• Router Advertisement with CGA option, RSA Signature option and the other related options can be used.

• If a non-AP STA has no certificate enough to verify, further exchanges of packets, for instance, Certification Path Solicitation/Advertisement, are required.

Slide 23

May 2012

Submission

doc.: IEEE 11-12/0273r9May 2012





The TGai amendment defines a mechanism to provide IPv4/IPv6 address assignment to STAs during the authentication procedure.

Submission

doc.: IEEE 11-12/0273r9May 2012





5.x Indication of availability of IP address configuration during association

The TGai amendment defines a method to enable a non-AP STA to know IP address configuration during association prior of the TGai association process.

Submission

doc.: IEEE 11-12/0273r9May 2012





5.x Indication of availability of higher layer protocols

The TGai amendment defines a method to enable a non-AP STA to know availability of higher layer protocols in advance of the TGai association process.

Submission

doc.: IEEE 11-12/0273r9May 2012





5.x IPv4 support

The TGai amendment defines a method of IP(v4) address assignment which works as a transport of DHCP.

Submission

doc.: IEEE 11-12/0273r9May 2012





5.x IPv6 stateless autoconfiguration support

The TGai amendment defines a method of IPv6 stateless address autoconfiguration which works as a transport of ICMPv6 RS/RA.

Submission

doc.: IEEE 11-12/0273r9May 2012





5.x IPv6 stateful autoconfiguration support

The TGai amendment defines a method of IPv6 stateful address autoconfiguration which works as a transport of ICMPv6 RS/RA and DHCPv6.

Submission

doc.: IEEE 11-12/0273r9May 2012





5.x Miscellaneous protocol support

The TGai amendment is open to other higher layer protocols and their services than IPv4 and IPv6.

Submission

doc.: IEEE 11-12/0273r9


Summary of Proposed Amendments

• HLCF Security: Assure that HLCF works safely.

• Protocols we support at least: IPv4 and IPv6

• Indication of availability in beacons or something:• IPv4/IPv6 address assignment

• higher layer configuration services (generalized text)

• Supported protocols in detail:• IPv4 DHCP

• IPv6 stateless configuration

• IPv6 stateful configuration

• other miscellaneous protocols

Slide 31

May 2012

Submission

doc.: IEEE 11-12/0273r9May 2012


Motion 2

Move to add the following text to the Section 5 of SFD:

“5.x Forwarding of HLCF information

The TGai amendment defines HLCF as an AP forwards higher layer information between an non-AP STA and the others than the non-AP STA only either after successful authentication or with assurances of the same security level as the existing 802.11 security framework.”

Moved:

Seconded:

Yes: No: Abstain:

Submission

doc.: IEEE 11-12/0273r9May 2012


Motion 3


“The TGai amendment defines a mechanism to provide IPv4/IPv6 address assignment to STAs during the authentication procedure.”

Moved:

Seconded:

Yes: No: Abstain:

Submission

doc.: IEEE 11-12/0273r9May 2012


Motion 4


“5.x Indication of availability of IP address configuration during association

The TGai amendment defines a method to enable a non-AP STA to know IP address configuration during association prior of the TGai association process.”

Moved:

Seconded:

Yes: No: Abstain:

Submission

doc.: IEEE 11-12/0273r9May 2012


Motion 5


“5.x Indication of availability of higher layer protocols

The TGai amendment defines a method to enable a non-AP STA to know availability of higher layer protocols in advance of the TGai association process.”

Moved:

Seconded:

Yes: No: Abstain:

Submission

doc.: IEEE 11-12/0273r9May 2012


Motion 6


“5.x IPv4 support

The TGai amendment defines a method of IP(v4) address assignment which works as a transport of DHCP.”

Moved:

Seconded:

Yes: No: Abstain:

Submission

doc.: IEEE 11-12/0273r9May 2012


Motion 7


“5.x IPv6 stateless autoconfiguration support

The TGai amendment defines a method of IPv6 stateless address autoconfiguration which works as a transport of ICMPv6 RS/RA.”

Moved:

Seconded:

Yes: No: Abstain:

Submission

doc.: IEEE 11-12/0273r9May 2012


Motion 8


“5.x IPv6 stateful autoconfiguration support

The TGai amendment defines a method of IPv6 stateful address autoconfiguration which works as a transport of ICMPv6 RS/RA and DHCPv6.”

Moved:

Seconded:

Yes: No: Abstain:

Submission

doc.: IEEE 11-12/0273r9May 2012


Motion 9


“5.x Miscellaneous protocol support

The TGai amendment is open to other higher layer protocols and their services than IPv4 and IPv6.”

Moved:

Seconded:

Yes: No: Abstain:

Submission

doc.: IEEE 11-12/0273r9May 2012


Slide 40

Backup

Submission

doc.: IEEE 11-12/0273r9


New

sof

twar

e fo

r ne

w p

roto

col

A possible counterproposal

May 2012

Slide 41



TGai new protocol

DHCP Discover w/ RCO

TGai new protocol

DHCP Ack

Translation?

Translation?

Submission

doc.: IEEE 11-12/0273r9


Comparison

DHCP with RCO New protocol w/ DHCP-like frame format

New protocol

Frame exchange 1 round trip 1 round trip 1 round trip

Non-AP STA is DHCP client TGai client TGai client

AP is a forwarder often a DHCP client often a DHCP client

TGai is a transport a protocol for IP address assignment

a protocol for IP address assignment

What information is distributed? DHCP defines DHCP defines (including

future extensions?) TGai defines

Behavior of non-AP STA DHCP defines TGai defines TGai defines

Behavior of AP a forwarder TGai defines TGai defines

AP has no state some state(?) some state(?)

When an address assignment expires

DHCP uses normal transport to extend

TGai defines extending procedure

TGai defines extending procedure

Slide 42

May 2012

Submission

doc.: IEEE 11-12/0273r9May 2012


Slide 43

IPv6 Internet Drafts

Considerations on M and O Flags of IPv6 Router Advertisement (draft-ietf-ipv6-ra-mo-flags-01)

Default Router and Prefix Advertisement Options for DHCPv6 (draft-droms-dhc-dhcpv6-default-router-00)

submission doc.: ieee 11-12/0273r9 may 2012 hiroki nakano, trans new technology, inc.slide 1 sfd...

Documents