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)
