Talk:IPsec

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. 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. 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 — 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. — Matt Crypto 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.

Rationale

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.

—Preceding unsigned comment added by 81.5.119.163 (talk) 03:30, 17 July 2010 (UTC)

According to Forouzan (2007; Data communications and networking; 4th ed), IPSec operates at the network layer of the OSI model. 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. 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." —Preceding unsigned comment added by 128.147.248.126 (talk) 22:29, 2 July 2008 (UTC)

AH with ESP

I think a section about AH used with ESP could be added. --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? Luis F. Gonzalez 03:25, 6 July 2007 (UTC)

FTP Example

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)

You're right. Done. 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. -- 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. Paul Koning 22:32, 11 November 2007 (UTC)

According to rfc6434, IPsec in IPv6 is now optional. 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". 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? --lynX (talk) —Preceding comment was added at 14:34, 3 January 2008 (UTC)

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)

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. --lynX (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, 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)

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)

According to RFC 6434, IPsec in IPv6 is now optional. Tobox (talk) 07:09, 5 October 2012 (UTC)

Open Directory Project Links

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)

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. — Rlevse • Talk • 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." 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. 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. — Preceding unsigned comment added by 66.169.108.251 (talk) 22:14, 9 September 2011 (UTC)

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. 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. 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. 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 (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 (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. Johnuniq (talk) 07:49, 18 February 2012 (UTC)

99.90.197.87 has been blocked for a month for edit warring. Just FYI. 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 — Preceding unsigned comment added by 167.211.190.10 (talk) 20:31, 11 March 2013 (UTC)

Introduction ignores layer 2 encryption

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)

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"? 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.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 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.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 08:58, 10 November 2017 (UTC)

First open source implementation

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

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.

(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? I welcome feedback, questions, and comments! (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 I welcome feedback, questions, and comments! (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. 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 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)