View source for Talk:IPsec

{{WikiProject banner shell|class=C|
{{WikiProject Computing |importance=High |network=yes |security=yes |network-importance=High |security-importance=Top}}
}}
==Thoughts==
I think the terminology is a bit confusing. ESP provides authenticity the article says. Authenticity of what? If it is origin authenticity that is meant I think that should clarified. --Fylke
: I have now spent a while reading the RFC for ESP and arrived at the conclusion that it is indeed ''origin authenticity'' that is provided. This is provided by verifying the SA (which in its turn is verified by the MAC). --Fylke

What about how switches and routers have to deal with ESP packets. If there normal IP headers have been removed then how do switches know how to route the packet?
: It is my understanding that with ESP you do not touch the header, as the name implies only the ''payload'' is encrypted. --Fylke
::Switches do not look at IP headers at all.  Routers need an IP header, and they get one; in transport mode the header is not encrypted and in tunnel mode an extra external IP header is added to the packet.  [[User:194.47.144.5|194.47.144.5]] 22:24, 17 Jan 2005 (UTC)

Is there any place where I can verify the below information?
{extract}
''IPsec can be used to create Virtual Private Networks (VPN) in either mode, and this is the dominant use. Note, however, that the security implications are quite different between the two operational modes.
''
(/extract}
== IPsec deserves a much better written article on Wikipedia ==
Introduction, background, history, technical details: ESP, AH, IKE and their evolution across generations of IPsec standards, SPD, SADB, TFC, critique (complexity), inaccessible RFCs, deployment scenarios, future. (I'll flesh it out some more in due course)

→What's with all the bolding of just about every keyword in the first section?  It isn't even continous throughout the article, so it sticks out quite a bit. [[User:Ggfevans|Ggfevans]] 21:23, 11 December 2006 (UTC) 

== Pronunciation ==

Someone, please correct the pronunciation at the beginning of the text (make it readable and by some standard)
: I've removed it &mdash; I'm not convinced it's particularly necessary. 21:17, 11 May 2005 (UTC)

== Design Intent rambling ==

The second paragraph under the Design Intent section is largely unsupportable and unnecessary.  Blaming the lack of IPsec adoption on lag is certainly questionable.  Blaming the ignorance of "many users" is also suspect.  At most, what can be supported is the lack of public key infrastructure and that IPv4, which does not mandate IPsec, remains dominant.

== Design Intent, Background, Goals ==


What does spam have to do with IPsec ... ?

The design intent needs to be rewritten.  Seems like some background and history on SDNS/NLSP would be useful since that is were IPsec originated.
Should be references to PAMPERS, BLACKER, CANEWARE, NES ...

What about SKIP ... dual stack versus in-line keymanagement is a signifiant characteristic of IPsec.

== Awful article, in the non-technical parts ==

Why is there this rambling about spam ?

And the supposed controversy about IPsec implementation in the linux kernel have nothing to do here.

The article also lacks an high level (non-tech) view and should mention PPTP, if only to point to the different approaches between the two.
: Yeah, I agree with you (although I think it doesn't hurt to mention the Linux IPsec stuff briefly). If you have the time and interest, please do dive in and fix things up. [[User:Matt Crypto|&mdash; Matt <small>Crypto</small>]] 10:07, 26 August 2005 (UTC)

== IPsec compared to other ... ==
This confuses me:
"it cannot rely on TCP (layer 4 OSI model) to manage reliability and fragmentation."  The article just got finished saying that it operates at the network layer and that UDP and TCP can be put on top of it.  Nothing below TCP "relies" on TCP then... TCP relies on IPsec, doesn't it?  You don't lose any reliability with TCP/IPsec/IP instead of TCP/IP, do you? -- Jesse (2006-02-21)

:The article says IPsec is an [[Internet layer]] protocol. However, it is not. It works as an additional, optional "[[presentation layer]]" above IP and below TCP/UDP/whatever. Consequently, it doesn't add or steal any "reliability" in TCP's terms.

{{hidden|style="class: Navbox;"|header=Rationale|content=Internet layer responsibilities are just delivering the packet across networks. Every packet is independent, there's no 'session' between source and destination and, consequently, no keys or anything can be associated with any 'source-destination' pair. The fact that IPsec works ''above'' IP, not replacing it, and has its own value in the latter's 'payload protocol' field, confirms the fact it's above I-net layer and is a transport protocol from IP's point of view.

On the other hand, IPsec doesn't perform any Transport layer responsibilities. It doesn't maintain packet order or detect lost packets. Neither does it belong to Session layer: the latter considers the stream as a whole and routes it to applications while IPsec doesn't. IPsec does look like a Presentation layer protocol. It does just this: specifies how the payload is encoded. It's not the 'OSI's Presentation layer' though. It's the ''presentation layer where TCP/UDP is considered the application''.}}  <span style="font-size: smaller;" class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/81.5.119.163|81.5.119.163]] ([[User talk:81.5.119.163|talk]]) 03:30, 17 July 2010 (UTC)</span><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

According to Forouzan (2007; Data communications and networking; 4th ed), IPSec operates at the network layer of the OSI model. [[User:Ksylian|Ksylian]] ([[User talk:Ksylian|talk]]) 13:07, 6 April 2011 (UTC)

== Slow Adoption - NAT routers ==

Under design intent, the article mentions a couple of reasons for slow adoption of IPSEC.   I beleive there are additional key reasons, not mentioned, that IPSEC has been slow to take off.  Primary among these is incompatability with NATs.   As I understand it, this is because the authentication portions of the protocol sign details including source IP and port numbers, which NATs must modify as part of their operation.  It sounds however like the more recent RFCs have standardized an approach that can flow through NATs, an important development.
[[User:Burt Harris|Burt Harris]] 14:51, 6 June 2006 (UTC)

I totally agree with the above.  People need to cite the NAT difficulties as a *major* reason that IPSEC is not implemented widely.  Of course, this will partially be solved in IPv6.  However, at the current state, the reason that I (and many other people) do not use IPSEC in favor of easier solutions (e.g. SSH) is due to the incompatibilities and weird characteristics of routers, primarily NATted ones.  My road warriors are not able to know in advance whether their conference center will provide them with a 10.x.x.x or 192.168.x.x or real IP, and whether the provider's routers are configured correctly (liberally) or block ports and drop packets in the name of their own "security."  <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/128.147.248.126|128.147.248.126]] ([[User talk:128.147.248.126|talk]]) 22:29, 2 July 2008 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->

== AH with ESP ==
I think a section about AH used with ESP could be added.
--[[User:220.101.89.242|220.101.89.242]] 01:52, 1 December 2006 (UTC)

== Encapsulating Security [Payload|Protocol] ==
Ok, I read the RFCs and they seem to change between Payload to Protocol. The RFC titles refer to Payload but section 3 refers to Protocol. Is there a clear rule on this? [[User:Luis F. Gonzalez|Luis F. Gonzalez]] 03:25, 6 July 2007 (UTC)

== FTP Example ==
I don't see how that example is relevant. I recommend removing it.  <small>—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/192.54.144.229|192.54.144.229]] ([[User talk:192.54.144.229|talk]]) 16:57, 11 September 2007 (UTC)</small><!-- Template:UnsignedIP --> <!--Autosigned by SineBot-->
: You're right.  Done.  [[User:Paul Koning|Paul Koning]] 19:14, 11 September 2007 (UTC)

== IPv6 ==
The wording in the article should be clarified a bit on IPv6. IPsec was a mandatory part when the IPv6 specification was written, but this only means that they tried to write the spec so that implementing IPsec should be easy, not that all traffic in IPv6 has be be encrypted. A lot of people see to misunderstand this, and think that all traffic across IPv6 '''has''' to be encrypted. This has become one of the biggest myths surrounding IPv6, and I think the article should be clarified to make it clear that packets across IPv6 will '''not''' be encrypted be default. -- [[User:StoneIsle|StoneIsle]] 11:50, 11 November 2007 (UTC)
: Good point.  I added "mandatory to implement, not mandatory to use" -- a distinction made many places in IETF standards. [[User:Paul Koning|Paul Koning]] 22:32, 11 November 2007 (UTC)
:: According to rfc6434, IPsec in IPv6 is now optional. [[User:Tobox|Tobox]] ([[User talk:Tobox|talk]]) 07:07, 5 October 2012 (UTC)

== Needs redirect ==

[[IPv4 security]] should redirect here. 21:19, 11 December 2007 (UTC)

: I created a redirect page for "IP security". [[User:Paul Koning|Paul Koning]] ([[User talk:Paul Koning|talk]]) 15:33, 12 December 2007 (UTC)

== Perfect forward secrecy anyone? ==
Is it correct IPsec provides no [[perfect forward secrecy]], not even by negotiation? --[[User:SymlynX|lynX]] ([[User talk:SymlynX|talk]])  <small>—Preceding [[Wikipedia:Signatures|comment]] was added at 14:34, 3 January 2008 (UTC)</small><!--Template:Undated--> <!--Autosigned by SineBot-->

: Incorrect, and in fact the article on [[perfect forward secrecy]] says so.  PFS is a negotiated option in IPsec, or more precisely in the key establishment protocol IKE. [[User:Paul Koning|Paul Koning]] ([[User talk:Paul Koning|talk]]) 16:12, 3 January 2008 (UTC)

Thanks, I fixed the article to show the information in the list of current protocols supporting it, not in ''history'' which may not always grab somebody's attention. --[[User:SymlynX|lynX]] ([[User talk:SymlynX|talk]]) 00:28, 15 January 2008 (UTC)

== IPsec - mandatory? ==

This article states: "IPsec implementation is a mandatory part of IPv6".

[[IPv6]] states: "IPsec, the protocol for IP network-layer encryption and authentication, is an integral part of the base protocol suite in IPv6".

However, [http://www.ietf.org/rfc/rfc2460.txt RFC 2460] mentions IPsec only in Changes since RFC 1883: "Changed the wording of the Security Considerations section to avoid dependency loop between this spec and the IPsec specs."

[http://tools.ietf.org/html/rfc2401 RFC 2401] never states that IPsec is mandatory.

As I see it, RFC 1883 mandate IPsec and RFC 3460 removed the mandate; thus IPsec is an option.  --<i><b>—&nbsp;[[User:Gadget850|<span style="color:gray;">Gadget850&nbsp;(Ed)</span>]]&nbsp;[[User talk:Gadget850|<sup style="color:darkblue;">''talk''</sup>]]</b> - </i> 13:35, 31 March 2008 (UTC)

: See RFC 4294 ("IPv6 Node Requirements") which says in section 8: 
<blockquote>8.  Security
<br>
   This section describes the specification of IPsec for the IPv6 node.
<br>
8.1.  Basic Architecture<br>
   Security Architecture for the Internet Protocol [RFC-4301] MUST be
   supported.
</blockquote>
[[User:Paul Koning|Paul Koning]] ([[User talk:Paul Koning|talk]]) 18:50, 31 March 2008 (UTC)

:: According to [http://tools.ietf.org/html/rfc6434 RFC 6434], IPsec in IPv6 is now optional. [[User:Tobox|Tobox]] ([[User talk:Tobox|talk]]) 07:09, 5 October 2012 (UTC)

== Open Directory Project Links ==

The [[template:dmoz2|DMOZ search template]], and by implication all DMOZ search links, is being considered for deletion because it violates [[WP:ELNO|WP:ELNO #9]]. Anyone interested in discussing the fate of Open Directory Project (DMOZ) search links is invited to join the discussion at [[Wikipedia:Templates for deletion#Template:Dmoz2]]. [[User:Qazin|Qazin]] ([[User talk:Qazin|talk]]) 05:49, 8 November 2008 (UTC)

== Can Ipsec block ws-discovery ? ==
The default WS-discovery port is 3702. But when using ipsec to block accessing to the port, the machine still can be found

==AH and ESP==
Can someone elaborate in the article on how and why AH and ESP can both be used in both tunneling and transport mode? It's my understanding both can be used in both modes but the article doesn't come out and say this. <span style="font-family:Verdana,sans-serif"> — [[User:Rlevse|<b style="color:#060;"><i>R</i>levse</b>]] • [[User_talk:Rlevse|<span style="color:#990;">Talk</span>]] • </span> 01:26, 4 August 2010 (UTC)

==Errors in ESP description ==

"Unlike Authentication Header (AH), ESP does not protect the IP packet header".
This statement is not true. According to Forouzan (2007; Data communications and networking; 4th ed) AH adds the authentication header while ESP adds the header and the trailer. However, in both instances, an IP header is added after the protocol value is changed.
AH uses the entire packet in calculation of authentication data (data integrity), with the exception of some fields in the IP header. Data integrity ensures that the data has nor been modified during the transmission for the source to destination but it does NOT provide encryption. Therefore, an IP header is not encrypted and is NOT protected.
I changed "ESP does not protect the IP packet header" to "ESP ''in transport mode'' does not ''provide integrity and authentication for the entire IP packet''."
[[User:Ksylian|Ksylian]] ([[User talk:Ksylian|talk]]) 13:51, 6 April 2011 (UTC)
:It is tricky to describe AH and ESP in a correct yet comprehensible manner. Your text is probably ok, although it needs some fixing because "Unlike Authentication Header" makes it look like AH ''does do'' the things you say ESP in transport mode does not do. In tunnel mode, there are of course two IP headers: the actual IP header of the packet in transit, and the IP header of the encapsulated packet. It could be argued that the original text was better and accurate if one assumes that "IP header" refers to the packet in transit; the following sentence spells out what happens in tunnel mode. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 03:25, 7 April 2011 (UTC)

==AH been deprecated==
Since ESP can provide for authentication only without encryption if desired, the need for AH is questionable and the reasoning for its inclusion in the IPsec standard from the beginning given this is murky.  In Stallings latest text (2011 edition) he states that the use of AH has been deprecated, and it is only included in Ipsecv3 for backward compatibility.  Given this standing when the two protocols are discussed, I think the focus should be center mainly on ESP and give details.  The information for AH could be included at the end of the article for completeness, or referenced to a separate page.  I guess part of the concern would be how widespread the use of AH protocol in practice currently.  <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/66.169.108.251|66.169.108.251]] ([[User talk:66.169.108.251|talk]]) 22:14, 9 September 2011 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->

== protocol , algoritm ==

Those two where intermixed & now are more clearly moved to 2 corespondig sections . Info for those who stuck wondering what IP meass up here. [[Special:Contributions/99.90.197.87|99.90.197.87]] ([[User talk:99.90.197.87|talk]]) 06:50, 18 February 2012 (UTC)
:I also reverted your changes as they were unexplained (and the above is not at all clear, and the English expression is not reassuring), and the changes did not seem helpful. Please explain what the problem with the existing text is before making that change again. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 07:15, 18 February 2012 (UTC)
::It is self explanatory. What you do not understand?  You didn't even bother to read the changes since you acuse "and the English expression is not reassuring" . There is no sentence edits just sorting paragraphs to logical sections :|) .  Next time try harder. [[Special:Contributions/99.90.197.87|99.90.197.87]] ([[User talk:99.90.197.87|talk]]) 07:37, 18 February 2012 (UTC)
:::I see you have (for a third time) made your changes. A belief that the changes are not desirable with a lack of explanation to justify the changes is sufficient reason to revert them again—the standard procedure here is for a change to be made, then if another editor disagrees and reverts the change, the change should ''not'' be made again, but should be justified on the talk page. I checked more thoroughly what is involved in the changes and confirm that a couple of sections were moved, and a link ([[Windows Vista networking technologies#IPsec and Windows Firewall|IPsec in Windows Vista and later]]) deleted. The link does seem excessive, and if it is kept should be reworked. However, I see no logic to justify the moved sections.
:::In the old version ({{oldid|IPsec|477496170|permalink}}), the "Security architecture" section proceeded in a standard manner: IPsec uses AH, ESP, and SA (quick overview of each). The following subsections then expand on AH then ESP then SA. The changes move mention of AH and ESP further down, and start with an overview of SA (while mentioning the unexplained AH and ESP). Perhaps the suggestion is that an SA is not a protocol, and so some phrasing of the original was inappropriate. Possibly so, but the change does not seem helpful to me. [[User:Johnuniq|Johnuniq]] ([[User talk:Johnuniq|talk]]) 07:49, 18 February 2012 (UTC)
:::: 99.90.197.87 has been blocked for a month for edit warring.  Just FYI.  [[User:Dbrodbeck|Dbrodbeck]] ([[User talk:Dbrodbeck|talk]]) 01:01, 20 February 2012 (UTC)

== NSA backdoor? ==

http://bsd.slashdot.org/story/10/12/15/004235/fbi-alleged-to-have-backdoored-openbsds-ipsec-stack  <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/167.211.190.10|167.211.190.10]] ([[User talk:167.211.190.10|talk]]) 20:31, 11 March 2013 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->

== Introduction ignores layer 2 encryption==
[[Special:Permalink/613970667|IPSec at the time of this post]]. If the third paragraphs aim is to compare IPSec to other encryption schemes, then layer 2 encryption should also be mentioned as well as the benefit of encryption at ''upper layers''. Currently, the reader is left with the notion that ''Hence, only IPsec protects any application traffics over an IP network''. Layer 2 encryption also provides blanket application layer security, has good bandwidth utilization but is limited in the topologies where it is effective. Encryption at the ''upper layers'' have higher processing and bandwidth costs but are extremely flexible in their application scenarios. IPSec sits in the middle. --[[User:GGink|GGink]] ([[User talk:GGink|talk]]) 01:30, 11 July 2014 (UTC)

The "only IPsec" phrasing is also misleading in that there are actually plenty of other ways of securing things at layer 3 or below—e.g.: every VPN system, not only IPsec. Maybe "only security at layer 3 or below, like IPsec"? [[User:Rozzin|Rozzin]] ([[User talk:Rozzin|talk]]) 20:00, 19 August 2014 (UTC)

Isn't the statement that IPsec is "end-to-end" misleading? PGP-encrypted mail is end-to-end, but IPsec covers only part of the path.[[Special:Contributions/113.151.206.174|113.151.206.174]] ([[User talk:113.151.206.174|talk]]) 01:26, 22 June 2016 (UTC)

== External links modified ==

Hello fellow Wikipedians,

I have just modified one external link on [[IPsec]]. Please take a moment to review [[special:diff/809618333|my edit]]. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit [[User:Cyberpower678/FaQs#InternetArchiveBot|this simple FaQ]] for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20070416135452/http://www.ietf.org/html.charters/btns-charter.html to http://www.ietf.org/html.charters/btns-charter.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

{{sourcecheck|checked=false|needhelp=}}

Cheers.—[[User:InternetArchiveBot|'''<span style="color:darkgrey;font-family:monospace">InternetArchiveBot</span>''']] <span style="color:green;font-family:Rockwell">([[User talk:InternetArchiveBot|Report bug]])</span> 08:58, 10 November 2017 (UTC)

== First open source implementation ==

{{u|173.73.12.2}} [https://en.wikipedia.org/w/index.php?title=IPsec&diff=818615153&oldid=817516569 inserted] the following without citation. I have reverted pending better support for these claims. ~[[User:Kvng|Kvng]] ([[User talk:Kvng|talk]]) 19:25, 7 January 2018 (UTC)
{{blockquote|NRL's BSD-licensed IPsec implementation was both the 1st implementation and the 1st open-source implementation.  It remains available from web.mit.edu as of early 2018, although the IPsec specifications have slightly changed over the past 22 years.  The NRL implementation was based on 4.4 BSD and ran on both SPARC and x86 hardware.}}
{{blockquote|(NRL's implementation was BSD licensed with open source available from web.mit.edu and was the 1st implementation)}}

== Mr. "Or" writes very strange lead ==

"Because of the complexity or immaturity of the IP security protocols, the initial IPv4 was developed without or barely with security protocols such that the IP version was incomplete, open or left for further research development."

I have to say that the" or" clauses in here make this sentence totally incomprehensible. In the first one, the author's phrasing reads as though "complex" were a layman's term for "immature." In the second "or":, saying without or barely with is incredibly weird phrasing. In the last "or" we aren't told what "incomplete" or "open" means in the context of this sentence. I've been using IPv4 for a decent number of years now and it feels pretty complete to me, an average Wikipedia user. And in any case, the "or" reads like it's saying "I don't really remember what happened to that IPv4 stuff, I don't know if they ever even finished it... I think they did finish it but then they opened it and did research? Who knows it was all so long ago." 

I would have edited but I genuinely don't know what the thing is trying to say. Might it mean something like "At the time IPv4 was developed, the various IP security protocols available were either too complex, or not yet mature technologies, and so some components of IPv4 were not developed with built in security. However, since the initial launch IPv4, work has continued to enhance the security of its protocols. 

Or something vaguely like that?  [[User:Ludicous|I welcome feedback, questions, and comments!]] ([[User talk:Ludicous|talk]]) 17:33, 25 May 2018 (UTC)

My sentence was also a little confusing, and I think one issue is that the word Protocol is not specific enough, and is confusing here because it's being used to describe both the security protocols that are supposed to be securing users, and the protocols that are being secured  [[User:Ludicous|I welcome feedback, questions, and comments!]] ([[User talk:Ludicous|talk]]) 17:38, 25 May 2018 (UTC)

: I edited it down to "The initial IPv4 suite was developed with few security provisions." and moved the sentence to a third paragraph. Still not sure why the emphasis on IPv4 since IPsec was actually first developed for IPv6. [[User:Volunteer1234|Volunteer1234]] ([[User talk:Volunteer1234|talk]]) 13:48, 18 October 2018 (UTC)

== Merged Dead Peer Detection ==
I've merged [[Dead Peer Detection]] here, since it seems to fail the [[WP:GNG]] and meet [[WP:MERGEREASON]] number 4 (better presented in context here). Don't actually know if a section on keepalives is due; that might merit just a few sentences. The German Wikipedia has [https://de.wikipedia.org/w/index.php?title=IPsec&oldid=233161673 a whole section] on them, but it's unsourced so no indication of dueness. James S. Tiller's in-depth book doesn't mention it, but Bollapragada, Khalid, Wainner (2005, ISBN 9780134384160) does. Would appreciate advice from someone knowledgeable on this — [[User:DFlhb|DFlhb]] ([[User talk:DFlhb|talk]]) 19:24, 6 May 2023 (UTC)