1. Week #12 LWIPEP and LWIP Tunneling
教育部行動寬頻尖端技術人才培育計畫-小細胞基站聯盟中心
示範課程:行動與無線區網整合
Week #12 LWIPEP and LWIP Tunneling
助理教授：吳俊興
助教：王瑞元
國立高雄大學 資訊工程學系

2. Outline
LWIPEP
LWIP Tunneling
Protocol Details

3. Overview
The objective is to describe the use of encapsulation for IP packets over the LWIP Tunnel

4. LWIP(LTE WLAN Radio Level Integration with IPsec Tunnel)
Network Layer, Internet protocol
Encrypt the original packet
Add a new set of IP addresses
The connection between the eNB and the UE is transmitted by the IPsec tunnel
LWIP-SeGW

5. LWIPEP Entities RRC is in control of the LWIPEP configuration
Functions of the LWIPEP sublayer are performed by LWIPEP entities
For an LWIPEP entity configured at the eNB, there is a peer LWIPEP entity configured at the UE and vice versa
The LWIPEP entity responsible for encapsulating LWIPEP SDUs is referred to as the transmitter
The LWIPEP entity responsible for decapsulating LWIPEP PDUs is referred to as the receiver

6. LWIPEP Entities
An LWIPEP entity receives/delivers LWIPEP SDUs from/to upper layers (i.e. IP) and sends/receives LWIPEP PDUs to/from its peer LWIPEP entity via an LWIP Tunnel and E-UTRA
At the transmitting side, when an LWIPEP entity receives an LWIPEP SDU from upper layers, it constructs the corresponding LWIPEP PDU and delivers it to lower layers
At the receiving side, when an LWIPEP entity receives an LWIPEP PDU from lower layers, it reassembles the corresponding LWIPEP SDU and delivers it to upper layers
An LWIPEP entity delivers/receives the following LWIPEP PDU to/from a lower layer entity
LWIPEP data PDU

7. Overview Model of the LWIPEP Sublayer

8. Services Services provided to upper layers
The following services are provided by LWIPEP to upper layers (i.e. IP):
transfer of user plane data
Services expected from lower layers
The following services are expected by LWIPEP from lower layers (i.e. LWIP Tunnel and E-UTRA):

9. Functions
The following functions are supported by the LWIPEP sublayer:
Transfer of user plane data
Identification of the DRB identity to which the LWIPEP SDU belongs

10. UL Data Transfer Procedures
When receiving an LWIPEP SDU from upper layers, the LWIPEP entity shall form the LWIPEP PDU

11. DL Data Transfer Procedures
When receiving an LWIPEP PDU from lower layers, the LWIPEP entity shall:
If configured by upper layers to enable aggregation in DL:
Interpret the LWIPEP PDU as having both Key and Sequence Number fields included
Reorder received packets according to the Sequence Number field before delivering them to higher layers
Else:
Interpret the LWIPEP PDU as having Key field included

12. Handling of Unknown, Unforeseen and Erroneous Protocol Data
When an LWIPEP entity receives an LWIPEP PDU that contains reserved or invalid values, the LWIPEP entity shall:
Discard the received PDU

13. Protocol Data Units
An LWIPEP PDU is a bit string that is byte aligned (i.e. multiple of 8 bits) in length
Bit strings are represented by tables in which the most significant bit is the leftmost bit of the first line of the table, the least significant bit is the rightmost bit on the last line of the table, and more generally the bit string is to be read from left to right and then in the reading order of the lines

14. Protocol Data Units
The bit order of each parameter field within an LWIPEP PDU is represented with the first and most significant bit in the leftmost bit and the last and least significant bit in the rightmost bit
An LWIPEP SDU is a bit string that is byte aligned (i.e. multiple of 8 bits) in length
An LWIPEP SDU is included into an LWIPEP PDU from the first bit onward
Only one type of LWIPEP PDU is defined, i.e. LWIPEP data PDU

15. LWIPEP Data PDU
An LWIPEP data PDU consists of the LWIPEP header and the LWIPEP SDU
The LWIPEP header is populated

16. Formats and Parameters
LWIPEP header
A GRE header and has a fixed size of eight bytes (if only the Key field is included) or twelve bytes (if both the Key and Sequence Number fields are included)
The transmitter shall set the 5 LSB's of the Key field in the GRE header to the DRB Identity associated with the LWIPEP SDU and set the remaining MSB's to '0'

17. Formats and Parameters
If instructed by RRC to enable aggregation in UL or DL, the transmitter shall in addition include the Sequence Number field in the LWIPEP header
All other optional fields are unused, and the values of other fields shall be set

18. IPsec Internet Protocol Security (IPsec) is a network protocol suite
Authenticates and encrypts the packets of data sent over a network
IPsec includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to use during the session
IPsec can protect data flows between a pair of hosts (host-to-host), between a pair of security gateways (network-to-network), or between a security gateway and a host (network-to-host)

19. IPsec
Internet Protocol security (IPsec) uses cryptographic security services to protect communications over Internet Protocol (IP) networks
IPsec supports network-level peer authentication, data-origin authentication, data integrity, data confidentiality (encryption), and replay protection

20. IPsec
IPsec is an end-to-end security scheme operating in the Internet Layer of the Internet Protocol Suite
While some other Internet security systems in widespread use, such as Transport Layer Security (TLS) and Secure Shell (SSH), operate in the upper layers at the Transport Layer (TLS) and the Application layer (SSH).
Only IPsec protects all application traffic over an IP network
IPsec can automatically secure applications at the IP layer

21. IPsec History
In the late 1980s, US NIST developed a set of security protocols for the Internet
One of these, Security Protocol at layer-3 (SP3) was implemented in IP encryption devices sold by Motorola
The IPsec Encapsulating Security Payload (ESP) is a direct derivative of the SP3 protocol

22. IPsec History
In 1992, both research and implementation began at the US Naval Research Laboratory(NRL) on IP encryption
This NRL work ultimately led to the IP Security protocols standardized by the Internet Engineering Task Force(IETF)
Later, in December 1993, the Software IP Encryption protocol swIPe (protocol) was researched at Columbia University and AT&T Bell Labsby John Ioannidis and others

23. Security Architecture
The IPsec suite is an open standard. IPsec uses the following protocols to perform various functions:
Authentication Headers (AH) provides connectionless data integrity and data origin authentication for IP datagrams and provides protection against replay attacks

24. Security Architecture
Encapsulating Security Payloads (ESP) provides 
Confidentiality
Data-origin authentication
Connectionless integrity
An anti-replay service (a form of partial sequence integrity)
Limited traffic-flow confidentiality

25. Security Architecture
Security Associations (SA) provides the bundle of algorithms and data that provide the parameters necessary for AH and/or ESP operations
The Internet Security Association and Key Management Protocol (ISAKMP) provides a framework for authentication and key exchange, with actual authenticated keying material provided either by manual configuration with pre-shared keys, Internet Key Exchange (IKE and IKEv2), Kerberized Internet Negotiation of Keys (KINK), or IPSECKEY DNS records

26. Authentication Header
Authentication Header (AH) is a member of the IPsec protocol suite
AH guarantees connectionless integrity and data origin authentication of IP packets
Further, it can optionally protect against replay attacks by using the sliding window technique and discarding old packets

27. Authentication Header
In IPv4, AH prevents option-insertion attacks
In IPv6, AH protects both against header insertion attacks and option insertion attacks
In IPv4, the AH protects the IP payload and all header fields of an IP datagram except for mutable fields (i.e. those that might be altered in transit), and also IP options such as the IP Security Option
Mutable (and therefore unauthenticated) IPv4 header fields are DSCP/ToS, ECN, Flags, Fragment Offset, TTL and Header Checksum

28. Authentication Header
In IPv6, the AH protects most of the IPv6 base header, AH itself, non-mutable extension headers after the AH, and the IP payload
Protection for the IPv6 header excludes the mutable fields: DSCP, ECN, Flow Label, and Hop Limit
AH operates directly on top of IP, using IP protocol number 51

29. Authentication Header Format

30. Authentication Header Format
Next Header (8 bits) Type of the next header, indicating what upper-layer protocol was protected
The value is taken from the list of IP protocol numbers
Payload Len (8 bits) The length of this Authentication Header in 4-octet units, minus 2
For example, an AH value of 4 equals 3×(32-bit fixed-length AH fields) + 3×(32-bit ICV fields) − 2 and thus an AH value of 4 means 24 octets
Although the size is measured in 4-octet units, the length of this header needs to be a multiple of 8 octets if carried in an IPv6 packet
This restriction does not apply to an Authentication Header carried in an IPv4 packet
Reserved (16 bits) Reserved for future use (all zeroes until then)

31. Authentication Header Format
Security Parameters Index (32 bits) Arbitrary value which is used (together with the destination IP address) to identify the security association of the receiving party
Sequence Number (32 bits) A monotonic strictly increasing sequence number (incremented by 1 for every packet sent) to prevent replay attacks
When replay detection is enabled, sequence numbers are never reused, because a new security association must be renegotiated before an attempt to increment the sequence number beyond its maximum value
Integrity Check Value (multiple of 32 bits) Variable length check value.
It may contain padding to align the field to an 8-octet boundary for IPv6, or a 4-octet boundary for IPv4

32. Encapsulating Security Payload
Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite
In IPsec it provides origin authenticity
Integrity and confidentiality protection of packets
ESP also supports encryption-only and authentication-only configurations, but using encryption without authentication is strongly discouraged because it is insecure

33. Encapsulating Security Payload
Unlike Authentication Header (AH), ESP in transport mode does not provide integrity and authentication for the entire IP packet
However, in Tunnel Mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected
ESP operates directly on top of IP, using IP protocol number 50

34. Encapsulating Security Payload Format

35. Encapsulating Security Payload Format
Security Parameters Index (32 bits) Arbitrary value used (together with the destination IP address) to identify the security association of the receiving party
Sequence Number (32 bits) A monotonically increasing sequence number (incremented by 1 for every packet sent) to protect against replay attacks
There is a separate counter kept for every security association
Payload data (variable) The protected contents of the original IP packet, including any data used to protect the contents (e.g. an Initialisation Vector for the cryptographic algorithm)
The type of content that was protected is indicated by the Next Header field

36. Encapsulating Security Payload Format
Padding (0-255 octets) Padding for encryption, to extend the payload data to a size that fits the encryption's cipher block size, and to align the next field
Pad Length (8 bits) Size of the padding (in octets)
Next Header (8 bits) Type of the next header. The value is taken from the list of IP protocol numbers
Integrity Check Value (multiple of 32 bits) Variable length check value. It may contain padding to align the field to an 8-octet boundary for IPv6, or a 4- octet boundary for IPv4

37. What IPsec Does
IPsec creates a boundary between unprotected and protected interfaces, for a host or a network
Traffic traversing the boundary is subject to the access controls specified by the user or administrator responsible for the IPsec configuration
These controls indicate whether packets cross the boundary unimpeded, are afforded security services via AH or ESP, or are discarded

38. How IPsec Works
IPsec uses two protocols to provide traffic security services -- Authentication Header (AH) and Encapsulating Security Payload (ESP)
IPsec implementations MUST support ESP and MAY support AH

39. How IPsec Works
The IP Authentication Header (AH) offers integrity and data origin authentication, with optional (at the discretion of the receiver) anti- replay features
Both AH and ESP offer access control, enforced through the distribution of cryptographic keys and the management of traffic flows as dictated by the Security Policy Database

40. How IPsec Works
The Encapsulating Security Payload (ESP) protocol offers the same set of services, and also offers confidentiality
Use of ESP to provide confidentiality without integrity is NOT RECOMMENDED
When ESP is used with confidentiality enabled, there are provisions for limited traffic flow confidentiality, i.e., provisions for concealing packet length, and for facilitating efficient generation and discard of dummy packets
This capability is likely to be effective primarily in virtual private network (VPN) and overlay network contexts

41. IPsec Tunnel Mode IPsec tunnel mode is the default mode
With tunnel mode, the entire original IP packet is protected by IPsec
This means IPsec wraps the original packet, encrypts it, adds a new IP header and sends it to the other side of the VPN tunnel (IPsec peer)
Tunnel mode is most commonly used between gateways (Cisco routers or ASA firewalls), or at an end-station to a gateway, the gateway acting as a proxy for the hosts behind it

42. IPsec Tunnel Mode
Tunnel mode is used to encrypt traffic between secure IPsec Gateways, for example two Cisco routers connected over the Internet via IPsec VPN
Configuration and setup of this topology is extensively covered in our Site-to-Site IPSec VPN article
In this example, each router acts as an IPsec Gateway for their LAN, providing secure connectivity to the remote network:

43. IPsec Tunnel Mode
Another example of tunnel mode is an IPsec tunnel between a Cisco VPN Client and an IPsec Gateway (e.g ASA5510 or PIX Firewall)
The client connects to the IPsec Gateway
Traffic from the client is encrypted, encapsulated inside a new IP packet and sent to the other end
Once decrypted by the firewall appliance, the client’s original IP packet is sent to the local network

44. IPsec Tunnel Mode with ESP Header
In tunnel mode, an IPsec header (AH or ESP header) is inserted between the IP header and the upper layer protocol. Between AH and ESP,  ESP is most commonly used in IPsec VPN Tunnel configuration
The packet diagram below illustrates IPsec Tunnel mode with ESP header:
ESP is identified in the New IP header with an IP protocol ID of 50

45. IPsec Tunnel mode with AH Header
The AH can be applied alone or together with the ESP, when IPsec is in tunnel mode
AH’s job is to protect the entire packet
The AH does not protect all of the fields in the New IP Header because some change in transit, and the sender cannot predict how they might change
The AH protects everything that does not change in transit
AH is identified in the New IP header with an IP protocol ID of 51

46. IPsec Transport Mode
IPsec Transport mode is used for end-to-end communications, for example, for communication between a client and a server or between a workstation and a gateway (if the gateway is being treated as a host)  
A good example would be an encrypted Telnet or Remote Desktop session from a workstation to a server

47. IPsec Transport Mode
Transport mode provides the protection of our data, also known as IP Payload, and consists of TCP/UDP header + Data, through an AH or ESP header
The payload is encapsulated by the IPsec headers and trailers
The original IP headers remain intact, except that the IP protocol field is changed to ESP (50) or AH (51), and the original protocol value is saved in the IPsec trailer to be restored when the packet is decrypted

48. IPsec Transport Mode
IPsec transport mode is usually used when another tunneling protocol (like GRE) is used to first encapsulate the IP data packet, then IPsec is used to protect the GRE tunnel packets
IPsec protects the GRE tunnel traffic in transport mode

49. IPsec Transport Mode with ESP header
Notice that the original IP Header is moved to the front
Placing the sender’s IP header at the front (with minor changes to the protocol ID), proves that transport mode does not provide protection or encryption to the original IP header and ESP is identified in the New IP headerwith an IP protocol ID of 50

50. IPsec Transport Mode with AH Header
The AH can be applied alone or together with the ESP when IPsec is in transport mode
AH’s job is to protect the entire packet, however, IPsec in transport mode does not create a new IP header in front of the packet but places a copy of the original with some minor changes to the protocol ID therefore not providing essential protection to the details contained in the IP header (Source IP, destination IP etc)
AH is identified in the New IP header with an IP protocol ID of 51
In both ESP and AH cases with IPsec Transport mode, the IP header is exposed

51. Summary
An LWIPEP entity receives/delivers LWIPEP SDUs from/to upper layers (i.e. IP) and sends/receives LWIPEP PDUs to/from its peer LWIPEP entity via an LWIP Tunnel and E- UTRA
IPsec works

52. References
TS Evolved Universal Terrestrial Radio Access (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec Tunnel (LWIP) encapsulation; Protocol specification
topics/protocols/870-ipsec-modes.html