Talk:IPsec

This article justifies an exception to the general rule against using an abbreviation as the main title. IPsec refers to several things, including the architecture and protocols, and is far more recognizable than "Internet Protocol Security". The latter is a bit misleading, as many security measures can be applied to the Internet Protocol; not all are IPsec. Howard C. Berkowitz 01:43, 16 October 2008 (UTC)

Initial text

Started article, first cut, using material from FreeS/WAN, see User_talk:Sandy_Harris/Permission. There's more from there to add, then it will need much editing. Sandy Harris 13:07, 15 October 2008 (UTC)

If so, FreeS/WAN needs to be cited.Howard C. Berkowitz 17:46, 15 October 2008 (UTC)

It is now both described and cited. Sandy Harris 04:46, 16 October 2008 (UTC)

Communications security/information assurance

I'd like to have one basic place where security functions, rather than enforcement mechanisms, are initially defined; there can, of course, be sub-articles. I started one called communications security, although I don't especially like the title. Information security or Information assurance might be alternatives, although I want to be sure the title encompasses:

• Features that would be in a computer, not just the communications channel
• Features that tend to be relevant just to the channel, such as frequency agility, protected distribution system, and combinations of spread spectrum with frequency agility (and even multiple antennas).

Suggestions? Once we agree on the title, I'd like the functions described in the lead to wikilink there, so IPSec can concentrate on a particular set of mechanisms. There may well be good reason to link to a separate set of articles on cryptographic algorithms.

Good idea, but I'm not certain of the best title. I don't like "assurance"; sounds to me like marketer-speak.

I have a related problem. Do active attack, passive attack, and other terms that can be defined in a few lines, get their own articles? Or do they redirect to sections of a longer more general article, perhaps Attack (cryptography) or Security flaws. If the latter, how do we control the scope? Sandy Harris 04:53, 16 October 2008 (UTC)

Authentication header

In my experience, there are applications where this is used, when the only requirement is for source authentication and header integrity. Could you give some citations about it not being used?Howard C. Berkowitz 17:46, 15 October 2008 (UTC)

I deleted that text. It was applicable for FreeS/WAN — which never implemented ESP-null and removed AH in later version — but likely not in general. Sandy Harris 04:55, 16 October 2008 (UTC)

Style and judgments

While an occasional subjective statement is not always out of place, unsourced judgment calls, or text that is argumentative, is just not encyclopedic style:

You can use ESP for encryption with AH for authentication: This has higher overheads than using the authentication in ESP, and no obvious benefit in most cases. The exception might be a network where AH authentication was widely or universally used. If you're going to do AH to conform with network policy, why authenticate again in the ESP layer?

It's perfectly reasonable to cite an article that asks these questions. In the absence of publications, but where the topic is, as the Patent Office puts it, "obvious to one skilled in the art", there may be justification to write a signed article. CZ isn't as compulsive as The Other Place about every word being sourced, but there is a line beyond which sourcing is needed. I think this text goes beyond that line. Might I ask it be rephrased or sourced? Howard C. Berkowitz 01:30, 16 October 2008 (UTC)

Rephrased. Sandy Harris 05:02, 16 October 2008 (UTC)

Again, style: second person is useful in many places, but is inconsistent with CZ style

CZ tries not to be "encyclopedish", but the style of "you can" is generally a little too informal. It's perfectly appropriate for the talk page, where we are actually (I hope) conversing. Look at other articles, though, and the second person style is not used. Howard C. Berkowitz 01:46, 16 October 2008 (UTC)

Changed most of those. Sandy Harris 04:57, 16 October 2008 (UTC)

Thanks. Howard C. Berkowitz 05:03, 16 October 2008 (UTC)

Citing RFCs

There are at least two ways to do this; just put in RFC 4303 and let the software automatically make it a link, or put in a formal citation such as . The article currently has both, the former from me and the latter from Howard.

I fairly strongly prefer the former, since it is easier for me and perhaps clearer to the reader. I could just keep doing it my way, and I won't object if someone edits that into the more formal version. However, it seems worth raising as a discussion topic.

Is there a policy on this? What is the reasoning behind using the longer form? Because it puts the links in the References section? Sandy Harris 06:29, 16 October 2008 (UTC)

In some cases, I think I prefer to put in everything. e.g. RFC 4303 "IP Encapsulating Security Payload (ESP)" . To me, though, the "RFC 4303" is the essential part; the other two are optional. Sandy Harris 08:20, 16 October 2008 (UTC)

I've tried it both ways, and I find the full method is best, putting, it does, the full citation into the references. For example, in DNSSEC, there may be a historic RFC that is the only place the transition is given. Without having the date, one has to to the RFC itself to find out whether a given coument is the most recent. If one is familiar with the workers in the field, the authorship can give perspective.

It's been an informal policy, to which there have been no objections up to now, about putting the full form into the cite. I'll write this up as a formal policy and put it into the style guide just starting on the workroup psge.Howard C. Berkowitz 13:42, 16 October 2008 (UTC)

Authentication header graphics

See if this is better -- it can be put back easily enough,less the comentary: IPsec packet authentication can be added in transport mode, as a modification of standard IP transport. This is shown in this diagram from the RFC:

                 BEFORE APPLYING AH
           ----------------------------
     IPv4  |orig IP hdr  |     |      |
           |(any options)| TCP | Data |
           ----------------------------

                 AFTER APPLYING AH
           ---------------------------------
     IPv4  |orig IP hdr  |    |     |      |
           |(any options)| AH | TCP | Data |
           ---------------------------------

Authentication can also be used in tunnel mode, encapsulating the underlying IP packet beneath AH and an additional IP header.

     +<==Delivery======><==========Payload==========>•••                 
     +------------------+----------------------------
IPv4 | new IP hdr* |    | orig IP hdr*  |    |      |
     |(any options)| AH | (any options) |TCP | Data |
     -----------------------------------------      |
     |                                              |
     |           in the new IP hdr                  |
     +-----------------------------------------------
     ••• ===========================================> (Remaining payload)

This would normally be used in a gateway-to-gateway tunnel. The receiving gateway then strips the outer IP header and the AH header and forwards the inner IP packet.

The mutable fields referred to are things like the time-to-live field in the IP header. These cannot be included in authentication calculations because they change as the packet travels.

Sandy, see if the modified ASCII art aboe works better. It may be advisable, if they are too hard to understand is ASCII, that full drawings, with color and shap coding for the pieces that remain hard to follow. See drawinr examples in, for example, Internet Protocol version 6 laboratory or [[Domain Name System security

From Citizendium, the Citizens' Compendium Jump to: navigation, search ]], just as examples of graphics. It you have PPT and the Great Firewall lets it though, I'm happy to send example that might serve as starting point.Howard C. Berkowitz 16:24, 16 October 2008 (UTC)

Authentication header graphics

See if this is better -- it can be put back easily enough,less the comentary: IPsec packet authentication can be added in transport mode, as a modification of standard IP transport. This is shown in this diagram from the RFC:

                 BEFORE APPLYING AH
           ----------------------------
     IPv4  |orig IP hdr  |     |      |
           |(any options)| TCP | Data |
           ----------------------------

                 AFTER APPLYING AH
           ---------------------------------
     IPv4  |orig IP hdr  |    |     |      |
           |(any options)| AH | TCP | Data |
           ---------------------------------

Authentication can also be used in tunnel mode, encapsulating the underlying IP packet beneath AH and an additional IP header.

     +<==Delivery======><==========Payload==========>•••                 
     +------------------+----------------------------
IPv4 | new IP hdr* |    | orig IP hdr*  |    |      |
     |(any options)| AH | (any options) |TCP | Data |
     -----------------------------------------      |
     |                                              |
     |           in the new IP hdr                  |
     +-----------------------------------------------
     ••• ===========================================> (Remaining payload)

This would normally be used in a gateway-to-gateway tunnel. The receiving gateway then strips the outer IP header and the AH header and forwards the inner IP packet.

The mutable fields referred to are things like the time-to-live field in the IP header. These cannot be included in authentication calculations because they change as the packet travels.

Sandy, see if the modified ASCII art above works better. It may be advisable, if they are too hard to understand is ASCII, that full drawings, with color and shap coding for the pieces that remain hard to follow. See drawinr examples in, for example, Internet Protocol version 6 laboratory or [[Domain Name System security

From Citizendium, the Citizens' Compendium Jump to: navigation, search ]], just as examples of graphics. It you have PPT and the Great Firewall lets it though, I'm happy to send example that might serve as starting point.Howard C. Berkowitz 16:24, 16 October 2008 (UTC)

Citation questions

I have questions on citation policy that directly affect this article, but are also broader that that. I've written them up at CZ_Talk:Article_Mechanics#Citation_relevance. Sandy Harris 15:23, 22 October 2008 (UTC)

Interop question

Moved from the article section on "Complications":

Is there any publication of this trial? At least in the IETF, when there's an N>2 implementation event, that generally gets written and becomes part of the package of documents for Full Standard.

You may also have another article fall out of this, on interoperability testingHoward C. Berkowitz 16:27, 16 October 2008 (UTC)

There were a whole series of "IPsec bakeoffs" and FreeS/WAN participated in several roughly 1999-2002. The FreeS/WAN interop document has some info; I have no other references. Web search turns up much discussion, mostly on the Working Group list, and fairly recent info on IKEv2 bakeoffs. Sandy Harris 16:30, 22 October 2008 (UTC)

First flow edit

Perhaps it's time to review a bit. For a complex protocol, or system of protocol, the top-level article is, IMHO, there to say what it does, not any real detail of how it does it. Now, there is a certain amount of how that has to go with the what. In DNS, for example, it doesn't make much sense beyond "magic" unless you have the basic idea that it is a federated data base of resource records.

In like manner, it's important for the IPsec reader to know about the services, limitations, and application-oriented operating modes (i.e., transport vs. tunnel). The reader needs to know that there are both management and user information flow components, and the limitations of the management protocols that are part of IPsec proper, such as IKE not doing PKI.

Yes, I think this needs quite a bit of work, probably including considerable rewriting or re-organising & some movement of topics to lower level articles. I've only dropped in some big chunks of text & done some light editing. Sandy Harris 09:52, 1 November 2008 (UTC)

Incidentally, the three main protocols are listed in two places: the introduction and the structure. We need one place, probably at the beginning; always define terms before using them.

Cryptographic components are far too detailed for the top level article; they belong in a separate article(s). I would make that article separate from, but, of course, highly linked with the actual protocol articles. Yes, there need to be IPsec Internet Key Exchange protocol, IPsec Authentication Header protocol, and IPsec Encapsulating Payload Security protocol subarticles;

Currently, there are links to Internet Key Exchange, Authentication Header, and Encapsulating Security Payload. Two are red; the other is currently a redirect into the part of this article that describes IKE, better than nothing since other articles link to that. All three might be started by moving text from here. Sandy Harris 04:55, 1 November 2008 (UTC)

let's think if there should be a general and specific cryptographic component subarticles. Remember, our most common reader is going to be using IPsec, a smaller group of readers will be administering, and the smallest will need to have an idea of the protocol operation — and we are still going to send that group to the RFCs.

Yes, At least block cipher, cryptographic hash and hashed message authentication code for IPsec, plus stream cipher to complete the set. I'm being bottom-up here; we can worry about re-organising IPsec once those are in hand. Sandy Harris 04:55, 1 November 2008 (UTC)

While some general words about implementation are appropriate at this level, we will want an IPsec deployment article or articles. Be careful about getting into too many details of the S/WAN work in the main article, if only that there some CZ procedures about making personal involvement clear. In some cases, this is best done on a Signed Article subpage. Certainly, the Canadian vs. U.S. issues are getting far beyond the level of detail in a general implementation article.

I started a FreeSWAN article, and simplified the text here. Sandy Harris 05:17, 1 November 2008 (UTC)

I don't want to discourage having that information in CZ, as it is a vivid and important examples of the especially complex policy issues that get involved in cryptography. In fact, it may be perfectly reasonable to have specific articles on some of the architecture and deployment controversies; there will be people that are fascinated by those. At the same time, there are going to be people that simply want to know what comes out of the box from Microsoft and Cisco. They may be interested in security functionality at the level of information security. No, we won't have Dilbert's pointy-headed boss (I'm going to have to define that, and then disambiguate Per-Hop Behavior from Pointy-Headed Boss. Really) reading this, but we are going to have more management people that simply don't care about open source politics, export control policy formation, etc. Of course, that's the beautiful thing about hyperdocuments — just click to get to the level of detail you need.

I thought it was Pointy-Haired Boss. One guy I worked for had quite long hair and would grab it and make it into points sometimes, usually when laying down policy. Sandy Harris 09:57, 1 November 2008 (UTC)

Fact-checking here is more than welcome; there is now a Dilbert article, and at least a PHB (disambiguation) :-)

For example, I'm very concerned about interoperability, performance and security strength, but, a while ago, I decided that while I have enough math to follow and edit general discussions of the encryption algorithms, they just don't interest me enough to learn to derive a partial elliptical function. I'm looking at things like block cipher from the standpoint of one who needs to know what various ones will do, but not necessarily how. You might not be as interested as I am in the details of routing protocol theory and what we do in the next generation.

So, as I've had to teach myself, whenever you start thinking of splitting articles, it may be a good idea. Technically, CZ gives, I believe, better tools that WP for organizing. While Related Articles and some other things still need substantial tweaking, I am taking such things as the SIGINT articles and doing some restructuring around CZ paradigms it took me a while to understand, and some of which are still being developed.

At the same time, remember always to link upwards to the more general. In many cases, that can be as simple as having {{main|next level article}} at the top of articles or sections. It can also be useful to have {{seealso|information security}} or some other pointers to more general material. These templates give an organizing flair that simple links do not. Howard C. Berkowitz 20:07, 31 October 2008 (UTC)