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)