Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Special pages
Niidae Wiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
IPsec
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===Encapsulating Security Payload=== [[File:Ipsec-esp-tunnel-and-transport.svg|thumb|Usage of IPsec Encapsulating Security Payload (ESP) in Tunnel and Transport modes]] The IP Encapsulating Security Payload (ESP)<ref>{{cite web | url = http://www.toad.com/gnu/draft-ietf-sip-esp-00.txt | title = SIPP Encapsulating Security Payload | publisher = IETF SIPP Working Group | year = 1993 | access-date = 2013-08-07 | archive-url = https://web.archive.org/web/20160909031941/http://www.toad.com/gnu/draft-ietf-sip-esp-00.txt | archive-date = 2016-09-09 | url-status = dead }}</ref> was developed at the [[Naval Research Laboratory]] starting in 1992 as part of a [[DARPA]]-sponsored research project, and was openly published by [[IETF]] SIPP<ref>{{cite web | url = http://tools.ietf.org/html/draft-ietf-sipp-spec-00 | title = Draft SIPP Specification | publisher = IETF | year = 1993 | page = 21| last1 = Deering | first1 = Steve E. }}</ref> Working Group drafted in December 1993 as a security extension for SIPP. This [[#Encapsulating Security Payload|ESP]] was originally derived from the US Department of Defense [[SP3D]] protocol, rather than being derived from the ISO Network-Layer Security Protocol (NLSP). The SP3D protocol specification was published by [[NIST]] in the late 1980s, but designed by the Secure Data Network System project of the [[US Department of Defense]]. Encapsulating Security Payload (ESP) is a member of the IPsec protocol suite. It provides origin [[Information security#Authenticity|authenticity]] through source [[authentication]], [[data integrity]] through hash functions and [[confidentiality]] through [[encryption]] protection for IP [[Packet (information technology)|packet]]s. ESP also supports [[encryption]]-only and [[authentication]]-only configurations, but using encryption without authentication is strongly discouraged because it is insecure.<ref>{{cite conference | title=Problem Areas for the IP Security Protocols | book-title=Proceedings of the Sixth Usenix Unix Security Symposium | first=Steven M. | last=Bellovin | year=1996 | pages=1โ16 | place=San Jose, CA | url=https://www.cs.columbia.edu/~smb/papers/badesp.ps | access-date=2007-07-09|author-link=Steven M. Bellovin|format=[[PostScript]]}}</ref><ref>{{cite conference | title=Cryptography in theory and practice: The case of encryption in IPsec | book-title=Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004 | last1=Paterson|first1=Kenneth G.|last2=Yau|first2=Arnold K.L.|date=2006-04-24|pages=12โ29 | location=Berlin | url=http://eprint.iacr.org/2005/416 | access-date=2007-08-13|format=PDF}}</ref><ref>{{cite conference | title=Attacking the IPsec Standards in Encryption-only Configurations | book-title=IEEE Symposium on Security and Privacy, IEEE Computer Society |last1=Degabriele|first1=Jean Paul|last2=Paterson|first2=Kenneth G.|date=2007-08-09|format=PDF | pages=335โ349 | location=Oakland, CA | url=http://eprint.iacr.org/2007/125 | access-date=2007-08-13 }}</ref> Unlike [[Authentication Header|Authentication Header (AH)]], ESP in transport mode does not provide integrity and authentication for the entire [[IP packet (disambiguation)|IP packet]].<!--intentional link to disambig--> However, in [[Tunneling protocol|tunnel mode]], where the entire original IP packet is [[Information hiding|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.<ref name="iana" /> The following ESP packet diagram shows how an ESP packet is constructed and interpreted:{{Ref RFC|4303}} {{APHD|start|title=Encapsulating Security Payload format}} {{APHD|0|bits1=32|field1=Security Parameters Index}} {{APHD|4|bits1=32|field1=Sequence Number}} {{APHD|999|hoctets=8|hbits=64|bits1=64|border1=bottom|background1=mistyrose|field1=Payload Data}} {{APHD|999|bits1=8|border1=top|background1=mistyrose|field1={{nbsp}}|bits2=24|background2=linen|border2=bottom|field2={{nbsp}}}} {{APHD|999|bits1=32|border1=top-bottom|background1=linen|field1=(Padding)}} {{APHD|999|bits1=16|border1=top|background1=linen|field1={{nbsp}}|bits2=8|field2=Pad Length|bits3=8|field3=Next Header}} {{APHD|999|bits1=64|field1=Integrity Check Value{{break}}โฎ}} {{APHD|end}} ;{{APHD|def|name=Security Parameters Index|short=SPI|length=32 bits|text=Arbitrary value used (together with the destination IP address) to identify the [[security association]] of the receiving party.}} ;{{APHD|def|name=Sequence Number|length=32 bits|text=A [[monotonic]]ally increasing sequence number (incremented by 1 for every packet sent) to protect against [[replay attack]]s. There is a separate counter kept for every security association.}} ;{{APHD|def|name=Payload Data|length=variable|text=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.}} ;{{APHD|def|name=Padding|length=0-255 octets|text=Optional. Padding for encryption, to extend the payload data to a size that fits the encryption's [[Block cipher|cipher]] [[Block size (cryptography)|block size]], and to align the next field.}} ;{{APHD|def|name=Pad Length|length=8 bits|text=Size of the padding (in octets).}} ;{{APHD|def|name=Next Header|length=8 bits|text=Indicates the [[list of IP protocol numbers|protocol type]] of the ''Payload Data'',{{Ref RFC|4303|rsection=2.6}} like the value {{Mono|6}} for [[Transmission Control Protocol|TCP]]. As ESP is an encapsulation protocol, a value of {{Mono|4}} is also possible, indicating [[IP in IP]]. A value of {{Mono|41}} indicates [[IPv6]] encapsulated in [[IPv4]], e.g. [[6to4]]. The value {{Mono|59}} (meaning: ''No Next Header'') is used for dummy packets, which may be inserted in the stream, and which contents should be discarded.}} ;{{APHD|def|name=Integrity Check Value|short=ICV|length=variable|text=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]].}}
Summary:
Please note that all contributions to Niidae Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Encyclopedia:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Search
Search
Editing
IPsec
(section)
Add topic