2012年2月28日 星期二

IPSec: Anti-replay

RFC 4302: IP Authentication Header
http://tools.ietf.org/html/rfc4302

3.3.2. Sequence Number Generation
(......)
The sender assumes anti-replay is enabled as a default, unless otherwise notified by the receiver (see Section 3.4.3) or if the SA was configured using manual key management. Thus, typical behavior of an AH implementation calls for the sender to establish a new SA when the Sequence Number (or ESN) cycles, or in anticipation of this value cycling.

3.4.3. Sequence Number Verification
All AH implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti- replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the Sequence Number for the SA be disabled (via negotiation or manual configuration), as noted below.


RFC 4303: IP Encapsulating Security Payload (ESP)
http://tools.ietf.org/html/rfc4303
1. Introduction
The anti-replay service may be selected for an SA only if the integrity service is selected for that SA. The selection of this service is solely at the discretion of the receiver and thus need not be negotiated. However, to make use of the Extended Sequence Number feature in an interoperable fashion, ESP does impose a requirement on SA management protocols to be able to negotiate this feature (see Section 2.2.1 below).

2.2. Sequence Number
(........)
If anti-replay is enabled (the default), the transmitted sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA.

3.3.3. Sequence Number Generation
(.......)
If the key used to compute an ICV is manually distributed, a compliant implementation SHOULD NOT provide anti-replay service. If a user chooses to employ anti-replay in conjunction with SAs that are manually keyed, the sequence number counter at the sender MUST be correctly maintained across local reboots, etc., until the key is replaced. (See Section 5.)
(.......)
Note: If a receiver chooses to not enable anti-replay for an SA, then the receiver SHOULD NOT negotiate ESN in an SA management protocol. Use of ESN creates a need for the receiver to manage the anti-replay window (in order to determine the correct value for the high-order bits of the ESN, which are employed in the ICV computation), which is generally contrary to the notion of disabling anti-replay for an SA.

3.4.3. Sequence Number Verification
All ESP implementations MUST support the anti-replay service, though its use may be enabled or disabled by the receiver on a per-SA basis. This service MUST NOT be enabled unless the ESP integrity service also is enabled for the SA, because otherwise the Sequence Number field has not been integrity protected. Anti-replay is applicable to unicast as well as multicast SAs. However, this standard specifies no mechanisms for providing anti-replay for a multi-sender SA (unicast or multicast). In the absence of negotiation (or manual configuration) of an anti-replay mechanism for such an SA, it is recommended that sender and receiver checking of the sequence number for the SA be disabled (via negotiation or manual configuration), as noted below.

2012年2月20日 星期一

IPSec: Extended (64-bit) Sequence Numbers (ESN)

RFC 4302: IP Authentication Header
http://tools.ietf.org/html/rfc4302#page-8

2.5. Sequence Number
This unsigned 32-bit field contains a counter value that increases by one for each packet sent, i.e., a per-SA packet sequence number.
(.....)
The field is mandatory and MUST always be present even if the receiver does not elect to enable the anti-replay service for a specific SA.
(.....)
Thus, the sender MUST always transmit this field, but the receiver need not act upon it.

The sender's counter and the receiver's counter are initialized to 0 when an SA is established. (The first packet sent using a given SA will have a sequence number of 1; see Section 3.3.2 for more details on how the sequence number is generated.) If anti-replay is enabled (the default), the transmitted sequence number must never be allowed to cycle. Thus, the sender's counter and the receiver's counter MUST be reset (by establishing a new SA and thus a new key) prior to the transmission of the 2^32nd packet on an SA.

2.5.1. Extended (64-bit) Sequence Number
To support high-speed IPsec implementations, a new option for sequence numbers SHOULD be offered, as an extension to the current, 32-bit sequence number field. Use of an Extended Sequence Number (ESN) MUST be negotiated by an SA management protocol. Note that in IKEv2, this negotiation is implicit; the default is ESN unless 32-bit sequence numbers are explicitly negotiated. (The ESN feature is applicable to multicast as well as unicast SAs.)

The ESN facility allows use of a 64-bit sequence number for an SA. (See Appendix B, "Extended (64-bit) Sequence Numbers", for details.) Only the low-order 32 bits of the sequence number are transmitted in the AH header of each packet, thus minimizing packet overhead. The high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver and are included in the computation of the ICV, but are not transmitted.

3.3.3.2.2. Implicit Packet Padding and ESN
If the ESN option is elected for an SA, then the high-order 32 bits of the ESN must be included in the ICV computation. For purposes of ICV computation, these bits are appended (implicitly) immediately after the end of the payload, and before any implicit packet padding.

For some integrity algorithms, the byte string over which the ICV computation is performed must be a multiple of a blocksize specified by the algorithm. If the IP packet length (including AH and the 32 high-order bits of the ESN, if enabled) does not match the blocksize requirements for the algorithm, implicit padding MUST be appended to the end of the packet, prior to ICV computation. The padding octets MUST have a value of zero. The blocksize (and hence the length of the padding) is specified by the algorithm specification. This padding is not transmitted with the packet. The document that defines an integrity algorithm MUST be consulted to determine if implicit padding is required as described above. If the document does not specify an answer to this, then the default is to assume that implicit padding is required (as needed to match the packet length to the algorithm's blocksize.) If padding bytes are needed but the algorithm does not specify the padding contents, then the padding octets MUST have a value of zero.
Appendix B: Extended (64-bit) Sequence Numbers
http://tools.ietf.org/html/rfc4302#page-28
B3. Handling Loss of Synchronization due to Significant Packet Loss


RFC 4303: IP Encapsulating Security Payload (ESP)
http://tools.ietf.org/html/rfc4303
(skipping parts alike to AH)
2.2.1. Extended (64-bit) Sequence Number
(...)
The high-order 32 bits are maintained as part of the sequence number counter by both transmitter and receiver and are included in the computation of the ICV (if the integrity service is selected). If a separate integrity algorithm is employed, the high order bits are included in the implicit ESP trailer, but are not transmitted, analogous to integrity algorithm padding bits. If a combined mode algorithm is employed, the algorithm choice determines whether the high-order ESN bits are transmitted or are included implicitly in the computation. See Section 3.3.2.2 for processing details.

3.3.2.1. Separate Confidentiality and Integrity Algorithms
4. Compute the ICV over the ESP packet minus the ICV field. Thus, the ICV computation encompasses the SPI, Sequence Number, Payload Data, Padding (if present), Pad Length, and Next Header. (Note that the last 4 fields will be in ciphertext form, because encryption is performed first.) If the ESN option is enabled for the SA, the high-order 32 bits of the sequence number are appended after the Next Header field for purposes of this computation, but are not transmitted.

3.3.2.2. Combined Confidentiality and Integrity Algorithms

- The Sequence Number (or Extended Sequence Number, as appropriate) and the SPI are inputs to the algorithm, as they must be included in the integrity check computation. The means by which these values are included in this computation are a function of the combined mode algorithm employed and thus not specified in this standard.

3.3.3. Sequence Number Generation
If ESN (see Appendix) is selected, only the low-order 32 bits of the sequence number are transmitted in the Sequence Number field, although both sender and receiver maintain full 64-bit ESN counters. The high order 32 bits are included in the integrity check in an algorithm/mode-specific fashion, e.g., the high-order 32 bits may be appended after the Next Header field when a separate integrity algorithm is employed.
Appendix A: Extended (64-bit) Sequence Numbers
http://tools.ietf.org/html/rfc4303#page-38

RFC 4106 - The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
http://tools.ietf.org/html/rfc4106#page-5
5. AAD Construction


RFC 4543 - The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
http://tools.ietf.org/html/rfc4543#page-5
3.3. AAD Construction


RFC 5084 - Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)
http://tools.ietf.org/html/rfc5084
1.5. AES-GCM
(......)
AES-GCM has four inputs: an AES key, an initialization vector (IV), a plaintext content, and optional additional authenticated data (AAD). AES-GCM generates two outputs: a ciphertext and message
(......)
AAD is authenticated but not encrypted. Thus, the AAD is not included in the AES-GCM output. It can be used to authenticate plaintext packet headers. In the CMS authenticated-enveloped-data content type, authenticated attributes comprise the AAD.


RFC 4304 - Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
http://tools.ietf.org/html/rfc4304

A Cryptographic Tour of the IPsec Standards
http://eprint.iacr.org/2006/097.pdf

3.2 AH Sequence Number Field
(.....)
RFC 4302 allows an optional Extended Sequence Number (ESN) to be used. This is helpful in high-speed networks, where a 32-bit counter could easily overflow during normal operations. ESNs are 64 bits long, and the entire 64 bits is used in the MAC calculation by AH even though only the least significant 32 bits of the ESN are carried in the Sequence Number Field. For the purposes of MAC calculation, the most significant 32 bits are placed after the payload, meaning that the ESN is actually split into two parts rather than appearing as a sequence of 64 consecutive bits in the input to the MAC. This is somewhat unusual, but does allow the AH format to remain the same as that specified in RFC 2402 when 32 bit sequence numbers are used. The transmission of only half the ESN in AH leads to the need for a synchronization mechanism in the event that more than 232 consecutive packets are lost. This is addressed in [22, Appendix B3]. RFC 4302 indicates that the default setting is to use ESNs rather than 32 bit sequence numbers; RFC 4304 [24] explains how IKE can be modi¯ed to allow negotation of ESNs.

4.2 ESP Sequence Number Field
Sequence numbers, including Extended Sequence Numbers (ESNs), are treated in largely the same way in RFC 4303 as they are in the AH RFC, RFC 4302. In particular, their use by the receiver is optional, but their inclusion in ESP headers is mandatory. The only real difference is that sequence numbers must be ignored by the recipient if the relevant ESP SA specifies the NULL integrity protection algorithm (in other words, if the SA only offers encryption). In this situation, ESP cannot offer an anti-replay service. If a combined mode algorithm is in use, the most significant bits of an ESN may actually be transmitted; if separate integrity and encryption algorithms are used, these bits are not transmitted, but are included in the MAC calculation by placing them in the ESP trailer, so they are split into two parts (as in AH).

2012年2月19日 星期日

2012年2月14日 星期二

Notepad++

Notepad++ Home
http://notepad-plus-plus.org/

IPSec Fragmentation

RFC 4301 - Security Architecture for the Internet Protocol
http://tools.ietf.org/html/rfc4301
7. Handling Fragments (on the protected side of the IPsec boundary)
http://tools.ietf.org/html/rfc4301#page-66
Appendix D: Fragment Handling Rationale
http://tools.ietf.org/html/rfc4301#page-88

2012年2月10日 星期五

User Mode Linux (UML)

[wiki] User-mode Linux
http://en.wikipedia.org/wiki/User-mode_Linux

The User-mode Linux Kernel Home Page
http://user-mode-linux.sourceforge.net/

Jserv's blog: 透過 User-Mode-Linux 來學習核心設計 (1)
http://blog.linux.org.tw/~jserv/archives/001871.html

Jserv's blog: 透過 User-Mode-Linux 來學習核心設計 (2)
http://blog.linux.org.tw/~jserv/archives/001872.html

Gentoo Linux 文件 -- Gentoo Linux 開發員 User-Mode Linux 測試指南
http://www.gentoo.org/doc/zh_tw/uml.xml

UserModeLinux - DebianWiki
http://wiki.debian.org.tw/UserModeLinux

2012年2月5日 星期日

魏文侯問李克

說苑 : 政理 : 32 - 中國哲學書電子化計劃
http://ctext.org/text.pl?node=21716&if=gb
先秦兩漢 -> 儒家 -> 說苑 -> 政理
魏文侯問李克曰:「為國如何?」對曰:「臣聞為國之道,食有勞而祿有功,使有能而賞必行,罰必當。」文侯曰:「吾嘗罰皆當而民不與,何也?」對曰:「國其有淫民乎?臣聞之曰:奪淫民之祿以來四方之士;其父有功而祿,其子無功而食之,出則乘車馬衣美裘以為榮華,入則修竽琴、鍾石之聲而安其子女之樂,以亂鄉曲之教,如此者奪其祿以來四方之士,此之謂奪淫民也。」

2012年2月1日 星期三

Git commit generation number

Git Commit Generation Numbers - Stack Overflow
http://stackoverflow.com/questions/6702821/git-commit-generation-numbers

[RFC/PATCHv2 3/6] commit: add commit_generation function -- Git
http://www.spinics.net/lists/git/msg161165.html

[PATCH] Add a 'generation' number to commits -- Git
http://www.spinics.net/lists/git/msg161311.html



[wiki] Directed acyclic graph (DAG)
http://en.wikipedia.org/wiki/Directed_acyclic_graph

Open Firmware (OF) / device tree (DT)

[wiki] Open Firmware
http://en.wikipedia.org/wiki/Open_Firmware

Open Firmware Home Page (OpenFirmware.ORG)
http://www.openfirmware.org/



Device Tree Usage - FDTWiki
http://devicetree.org/Device_Tree_Usage

Device Tree - OMAPpedia
http://omappedia.org/wiki/Device_Tree

Kernel/Dev/ARMDeviceTrees - Ubuntu Wiki
Device Tree on ARM Linux kernel work
https://wiki.ubuntu.com/Kernel/Dev/ARMDeviceTrees?action=show&redirect=KernelTeam%2FARMDeviceTrees

Device-tree support for ARM
http://lwn.net/Articles/367752/

ARM Flattened Device Tree status report
http://elinux.org/images/b/b6/ARM_Device_Tree_Status_Report.pdf

[wiki] Flag day (software)

[wiki] Flag day (software)
http://en.wikipedia.org/wiki/Flag_day_%28software%29

Flag day ... is a change which requires a complete restart or conversion of a sizable body of software or data. The change is large and expensive, and—in the event it doesn't work—reversing the change is similarly difficult and expensive.

This usage originates from a change in the Multics operating system's definition of ASCII, which was scheduled for the U.S. holiday, Flag Day, on June 14, 1966.

Another flag day was January 1, 1983: when the ARPANET changed from NCP to the TCP/IP protocol suite.[