Talk:IPsec

From Wikipedia, the free encyclopedia

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}

Contents

[edit] 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)

[edit] 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)

[edit] 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.

[edit] 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.

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)