1 / 43

SFD Text for Upper Layers

SFD Text for Upper Layers. Authors:. Date: 2012-0 5 - 14. 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)

natan
Download Presentation

SFD Text for Upper Layers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SFD Text for Upper Layers Authors: • Date: 2012-05-14 Hiroki Nakano, Trans New Technology, Inc.

  2. 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: page32-39 including five motions Hiroki Nakano, Trans New Technology, Inc.

  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. Hiroki Nakano, Trans New Technology, Inc.

  4. Background Information for IPv4 • RFC2131 - Dynamic Host Configuration Protocol • RFC4039 - Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4) Hiroki Nakano, Trans New Technology, Inc.

  5. 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 Hiroki Nakano, Trans New Technology, Inc.

  6. 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) Hiroki Nakano, Trans New Technology, Inc.

  7. 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) Hiroki Nakano, Trans New Technology, Inc.

  8. 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. Hiroki Nakano, Trans New Technology, Inc.

  9. 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. Hiroki Nakano, Trans New Technology, Inc.

  10. Hiroki Nakano, Trans New Technology, Inc. Generalized Sequence AS and Conf. server can reside inside AP. Non-AP STA AP Conf. server Configuration Request Higher Layer Configuration Service AS Possibly Encrypted AP keeps a HLCF data. Maximum time is assumed to be less than 100 msec. Processing for security (See TGai Functional Requirements) less than 100ms At this point, Non-AP STA has been authenticated. Possibly Encrypted Configuration Reply

  11. Proposed Amendment 2 • Clause to amend: Section 5 • Add the following text: • 5.xForwarding of HLCF information • The TGai amendment defines HLCF as an APforwards informationcarried from an non-AP STA by HLCF to the others than the non-AP STA only either after successful authentication orwith assurances of the same security level as the existing802.11 security framework. Hiroki Nakano, Trans New Technology, Inc.

  12. Hiroki Nakano, Trans New Technology, Inc. Sequence Example by DHCP with RCO Non-AP STA AP DHCP server DHCP Discover w/ RCO DHCP Client Software AS Possibly Encrypted AP keeps a DHCP packet. Maximum time is assumed to be less than 100 msec. Processing for security (See TGai Functional Requirements) less than 100ms At this point, Non-AP STA has been authenticated. Possibly Encrypted DHCP Ack

  13. Hiroki Nakano, Trans New Technology, Inc. Sequence Example by ICMPv6 RS/RA Non-AP STA AP Router Router Solicitation Stateless Configuration Software AS Possibly Encrypted AP keeps a RS packet. Maximum time is assumed to be less than 100 msec. Processing for security (See TGai Functional Requirements) less than 100ms At this point, Non-AP STA has been authenticated. Possibly Encrypted Router Advertisement

  14. Hiroki Nakano, Trans New Technology, Inc. Sequence Example by DHCPv6 Non-AP STA AP Router Router Solicitation Stateful Configuration Software AS Possibly Encrypted AP keeps a RS packet. Maximum time is assumed to be less than 100 msec. Processing for security (See TGai Functional Requirements) less than 100ms At this point, Non-AP STA has been authenticated. Possibly Encrypted ICMPv6 RA with M flag DHCPv6 on 802.11 Data frames

  15. Hiroki Nakano, Trans New Technology, Inc. Sequence Example by DHCPv6 with RCO(challenging framework) Non-AP STA AP DHCP server DHCPv6 Solicit w/ RCO Stateful Configuration Software AS Possibly Encrypted AP keeps a DHCP packet. Maximum time is assumed to be less than 100 msec. Processing for security (See TGai Functional Requirements) less than 100ms At this point, Non-AP STA has been authenticated. Possibly Encrypted RA & DHCPv6 Reply

  16. 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. Hiroki Nakano, Trans New Technology, Inc.

  17. 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. Hiroki Nakano, Trans New Technology, Inc.

  18. 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. Hiroki Nakano, Trans New Technology, Inc.

  19. Hiroki Nakano, Trans New Technology, Inc. A Case with late Reply from Conf. server Non-AP STA AP Conf. server Configuration Request Higher Layer Configuration Service AS Possibly Encrypted Processing for security Possibly Encrypted (See TGai Functional Requirements) less than 100ms Association Response AP can abandon piggybacking after waiting for configured period. Configuration Reply Normal data frame

  20. 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. Hiroki Nakano, Trans New Technology, Inc.

  21. 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. Hiroki Nakano, Trans New Technology, Inc.

  22. 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. Hiroki Nakano, Trans New Technology, Inc.

  23. 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. Hiroki Nakano, Trans New Technology, Inc.

  24. Proposed Amendment 3 • Clause to amend: Section 5 • Add the following text: • The TGai amendment defines a mechanism to provide IPv4/IPv6 address assignment to STAs during the authentication procedure. Hiroki Nakano, Trans New Technology, Inc.

  25. Proposed Amendment 4 • Clause to amend: Section 5 • Add the following text: • 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. Hiroki Nakano, Trans New Technology, Inc.

  26. Proposed Amendment 5 • Clause to amend: Section 5 • Add the following text: • 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. Hiroki Nakano, Trans New Technology, Inc.

  27. Proposed Amendment 6 • Clause to amend: Section 5 • Add the following text: • 5.x IPv4 support • The TGai amendment defines a method of IP(v4) address assignment which works as a transport of DHCP. Hiroki Nakano, Trans New Technology, Inc.

  28. Proposed Amendment 7 • Clause to amend: Section 5 • Add the following text: • 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. Hiroki Nakano, Trans New Technology, Inc.

  29. Proposed Amendment 8 • Clause to amend: Section 5 • Add the following text: • 5.x IPv6 statefulautoconfiguration support • The TGai amendment defines a method of IPv6 stateful address autoconfiguration which works as a transport of ICMPv6 RS/RA and DHCPv6. Hiroki Nakano, Trans New Technology, Inc.

  30. Proposed Amendment 9 • Clause to amend: Section 5 • Add the following text: • 5.x Miscellaneous protocol support • The TGai amendment is open to other higher layer protocols and their services than IPv4 and IPv6. Hiroki Nakano, Trans New Technology, Inc.

  31. 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 Hiroki Nakano, Trans New Technology, Inc.

  32. Motion 2 • Move to add the following text to theSection 5 of SFD: • “5.xForwarding of HLCF information The TGai amendment defines HLCF as an APforwards higher layer informationbetween an non-AP STA and the others than the non-AP STA only either after successful authentication orwith assurances of the same security level as the existing802.11 security framework.” Moved: Seconded: Yes: No: Abstain: Hiroki Nakano, Trans New Technology, Inc.

  33. Motion 3 • Move to add the following text to theSection 5 of SFD: • “The TGai amendment defines a mechanism to provide IPv4/IPv6 address assignment to STAs during the authentication procedure.” Moved: Seconded: Yes: No: Abstain: Hiroki Nakano, Trans New Technology, Inc.

  34. Motion 4 • Move to add the following text to theSection 5 of SFD: • “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: Hiroki Nakano, Trans New Technology, Inc.

  35. Motion 5 • Move to add the following text to theSection 5 of SFD: • “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: Hiroki Nakano, Trans New Technology, Inc.

  36. Motion 6 • Move to add the following text to theSection 5 of SFD: • “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: Hiroki Nakano, Trans New Technology, Inc.

  37. Motion 7 • Move to add the following text to theSection 5 of SFD: • “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: Hiroki Nakano, Trans New Technology, Inc.

  38. Motion 8 • Move to add the following text to theSection 5 of SFD: • “5.x IPv6 statefulautoconfiguration 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: Hiroki Nakano, Trans New Technology, Inc.

  39. Motion 9 • Move to add the following text to theSection 5 of SFD: • “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: Hiroki Nakano, Trans New Technology, Inc.

  40. Backup Hiroki Nakano, Trans New Technology, Inc.

  41. Hiroki Nakano, Trans New Technology, Inc. Apossible counterproposal Non-AP STA AP DHCP server New software for new protocol TGai new protocol Processing for security Translation? DHCP Discover w/ RCO Translation? DHCP Ack TGai new protocol

  42. Comparison Hiroki Nakano, Trans New Technology, Inc.

  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) Hiroki Nakano, Trans New Technology, Inc.

More Related