Talk:IPsec

message: 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.  194.47.144.5 22:24, 17 Jan 2005 (UTC)
thread_title: Thoughts

message: 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. Ggfevans 21:23, 11 December 2006 (UTC)
thread_title:  IPsec deserves a much better written article on Wikipedia 

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

message: 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. — Matt Crypto 10:07, 26 August 2005 (UTC)
thread_title:  Awful article, in the non-technical parts 

message: 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.
  —Preceding unsigned comment added by 81.5.119.163 (talk) 03:30, 17 July 2010 (UTC)
thread_title:  IPsec compared to other ... 

message: 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.
Burt Harris 14:51, 6 June 2006 (UTC)
thread_title:  Slow Adoption - NAT routers 

message: I think a section about AH used with ESP could be added.
--220.101.89.242 01:52, 1 December 2006 (UTC)
thread_title:  AH with ESP 

message: 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? Luis F. Gonzalez 03:25, 6 July 2007 (UTC)
thread_title:  Encapsulating Security [Payload|Protocol] 

message: I don't see how that example is relevant. I recommend removing it.  —Preceding unsigned comment added by 192.54.144.229 (talk) 16:57, 11 September 2007 (UTC)
replies: text: You're right.  Done.  Paul Koning 19:14, 11 September 2007 (UTC)
thread_title:  FTP Example 

message: 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. -- StoneIsle 11:50, 11 November 2007 (UTC)
replies: text: Good point.  I added "mandatory to implement, not mandatory to use" -- a distinction made many places in IETF standards. Paul Koning 22:32, 11 November 2007 (UTC)
replies: text:  According to rfc6434, IPsec in IPv6 is now optional. Tobox (talk) 07:07, 5 October 2012 (UTC)
thread_title:  IPv6 

message: IPv4 security should redirect here. 21:19, 11 December 2007 (UTC)
replies: text: I created a redirect page for "IP security". Paul Koning (talk) 15:33, 12 December 2007 (UTC)
thread_title:  Needs redirect 

message: Is it correct IPsec provides no perfect forward secrecy, not even by negotiation? --lynX (talk)  —Preceding comment was added at 14:34, 3 January 2008 (UTC)
replies: text: 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. Paul Koning (talk) 16:12, 3 January 2008 (UTC)
thread_title:  Perfect forward secrecy anyone? 

message: 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, 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."
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.  --— Gadget850 (Ed) talk -  13:35, 31 March 2008 (UTC)
replies: text: See RFC 4294 ("IPv6 Node Requirements") which says in section 8: 
8.  Security
   This section describes the specification of IPsec for the IPv6 node.
8.1.  Basic Architecture
   Security Architecture for the Internet Protocol [RFC-4301] MUST be
   supported.
Paul Koning (talk) 18:50, 31 March 2008 (UTC)
replies: text:  According to RFC 6434, IPsec in IPv6 is now optional. Tobox (talk) 07:09, 5 October 2012 (UTC)
thread_title:  IPsec - mandatory? 

message: The DMOZ search template, and by implication all DMOZ search links, is being considered for deletion because it violates 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. Qazin (talk) 05:49, 8 November 2008 (UTC)
thread_title:  Open Directory Project Links 

message: 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.  — Rlevse • Talk •  01:26, 4 August 2010 (UTC)
thread_title: AH and ESP

message: "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."
Ksylian (talk) 13:51, 6 April 2011 (UTC)
replies: text: 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. Johnuniq (talk) 03:25, 7 April 2011 (UTC)
thread_title: Errors in ESP description 

message: 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.  — Preceding unsigned comment added by 66.169.108.251 (talk) 22:14, 9 September 2011 (UTC)
thread_title: AH been deprecated

message: http://bsd.slashdot.org/story/10/12/15/004235/fbi-alleged-to-have-backdoored-openbsds-ipsec-stack  — Preceding unsigned comment added by 167.211.190.10 (talk) 20:31, 11 March 2013 (UTC)
thread_title:  NSA backdoor? 

message: 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. --GGink (talk) 01:30, 11 July 2014 (UTC)
thread_title:  Introduction ignores layer 2 encryption

message: Hello fellow Wikipedians,
I have just modified one external link on IPsec. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit 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.
Cheers.—InternetArchiveBot (Report bug) 08:58, 10 November 2017 (UTC)
thread_title:  External links modified 

message: inserted the following without citation. I have reverted pending better support for these claims. ~Kvng (talk) 19:25, 7 January 2018 (UTC)
thread_title:  First open source implementation 

message: "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?  I welcome feedback, questions, and comments! (talk) 17:33, 25 May 2018 (UTC)
replies: text: 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. Volunteer1234 (talk) 13:48, 18 October 2018 (UTC)
thread_title:  Mr. "Or" writes very strange lead 

message: 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 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 — DFlhb (talk) 19:24, 6 May 2023 (UTC)
thread_title:  Merged Dead Peer Detection