correct references. update ipsec description (sync with kame).
This commit is contained in:
itojun
parent
1e2580bc32
commit
e8808e9659
|
|
@ -1,4 +1,4 @@
|
|||
$NetBSD: IMPLEMENTATION,v 1.10 2000/02/28 13:48:51 itojun Exp $
|
||||
$NetBSD: IMPLEMENTATION,v 1.11 2000/03/22 08:20:18 itojun Exp $
|
||||
|
||||
# NOTE: this is from original KAME distribution.
|
||||
# Some portion of this document is not applicable to the code merged into
|
||||
|
|
@ -8,7 +8,7 @@ $NetBSD: IMPLEMENTATION,v 1.10 2000/02/28 13:48:51 itojun Exp $
|
|||
|
||||
KAME Project
|
||||
http://www.kame.net/
|
||||
Date: 2000/02/24 16:53:19
|
||||
KAME Date: 2000/03/22 07:52:30
|
||||
|
||||
1. IPv6
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ draft-itojun-ipv6-tcp-to-anycast-00.txt:
|
|||
Disconnecting TCP connection toward IPv6 anycast address
|
||||
draft-yamamoto-wideipv6-comm-model-00.txt
|
||||
* See 1.6 in this document for details.
|
||||
draft-ietf-ipngwg-scopedaddr-format-??.txt:
|
||||
draft-ietf-ipngwg-scopedaddr-format-01.txt:
|
||||
An Extension of Format for IPv6 Scoped Addresses
|
||||
draft-ietf-ngtrans-tcpudp-relay-00.txt:
|
||||
An IPv6-to-IPv4 transport relay translator
|
||||
|
|
@ -230,7 +230,7 @@ Programs that use these APIs have to be prepared about differences
|
|||
in kernels anyway.
|
||||
|
||||
getaddrinfo(3) and getnameinfo(3) are modified to support extended numeric
|
||||
IPv6 syntax, as documented in draft-ietf-ipngwg-scopedaddr-format-??.txt.
|
||||
IPv6 syntax, as documented in draft-ietf-ipngwg-scopedaddr-format-01.txt.
|
||||
You can specify outgoing link, by using name of the outgoing interface
|
||||
like "fe80::1%ne0". This way you will be able to specify link-local scoped
|
||||
address without much trouble.
|
||||
|
|
@ -245,7 +245,7 @@ scope identifier.
|
|||
1.3.3 Interaction with users (command line)
|
||||
|
||||
Some of the userland tools support extended numeric IPv6 syntax, as
|
||||
documented in draft-ietf-ipngwg-scopedaddr-format-??.txt. In this case,
|
||||
documented in draft-ietf-ipngwg-scopedaddr-format-01.txt. In this case,
|
||||
you can specify outgoing link, by using name of the outgoing interface like
|
||||
"fe80::1%ne0".
|
||||
|
||||
|
|
@ -1137,6 +1137,15 @@ Basically you'll need to run racoon as daemon, then setup a policy
|
|||
to require keys (like ping -P 'out ipsec esp/transport//use').
|
||||
The kernel will contact racoon daemon as necessary to exchange keys.
|
||||
|
||||
In IKE spec, there's ambiguity about interpretation of "tunnel" proposal.
|
||||
For example, if we would like to propose the use of following packet:
|
||||
IP AH ESP IP payload
|
||||
some implmementation proposes it as "AH transport and ESP tunnel", since
|
||||
this is more logical from packet construction point of view. Some
|
||||
implementation proposes it as "AH tunnel and ESP tunnel".
|
||||
Racoon follows the former route.
|
||||
This raises real interoperability issue. We hope this to be resolved quickly.
|
||||
|
||||
4.3 AH and ESP handling
|
||||
|
||||
IPsec module is implemented as "hooks" to the standard IPv4/IPv6
|
||||
|
|
@ -1170,6 +1179,19 @@ Tunnel mode works basically fine, but comes with the following restrictions:
|
|||
the kernel configuration file. Note that path MTU discovery does not work
|
||||
across IPv6 IPsec tunnel gateway due to insufficient code.
|
||||
|
||||
AH specificaton does not talk much about "multiple AH on a packet" case.
|
||||
We incrementally compute AH checksum, from inside to outside. Also, we
|
||||
treat inner AH to be immutable.
|
||||
For example, if we are to create the following packet:
|
||||
IP AH1 AH2 AH3 payload
|
||||
we do it incrementally. As a result, we get crypto checksums like below:
|
||||
AH3 has checksum against "IP AH3' payload".
|
||||
where AH3' = AH3 with checksum field filled with 0.
|
||||
AH2 has checksum against "IP AH2' AH3 payload".
|
||||
AH1 has checksum against "IP AH1' AH2 AH3 payload",
|
||||
Also note that AH3 has the smallest sequence number, and AH1 has the largest
|
||||
sequence number.
|
||||
|
||||
4.4 IPComp handling
|
||||
|
||||
IPComp stands for IP payload compression protocol. This is aimed for
|
||||
|
|
@ -1190,12 +1212,16 @@ Here are some points to be noted:
|
|||
- pfkey is modified to support IPComp. However, there's no official
|
||||
SA type number assignment yet. Portability with other IPComp
|
||||
stack is questionable (anyway, who else implement IPComp on UN*X?).
|
||||
- Spec says that IPComp output processing must be performed before IPsec
|
||||
- Spec says that IPComp output processing must be performed before AH/ESP
|
||||
output processing, to achieve better compression ratio and "stir" data
|
||||
stream before encryption. However, with manual SPD setting, you are able to
|
||||
violate the ordering requirement (KAME code is too generic, maybe).
|
||||
- Though MTU can be significantly decreased by using IPComp, no special
|
||||
consideration is made about path MTU (spec talks nothing about MTU
|
||||
stream before encryption. The most meaningful processing order is:
|
||||
(1) compress payload by IPComp, (2) encrypt payload by ESP, then (3) attach
|
||||
authentication data by AH.
|
||||
However, with manual SPD setting, you are able to violate the ordering
|
||||
(KAME code is too generic, maybe). Also, it is just okay to use IPComp
|
||||
alone, without AH/ESP.
|
||||
- Though the packet size can be significantly decreased by using IPComp, no
|
||||
special consideration is made about path MTU (spec talks nothing about MTU
|
||||
consideration). IPComp is designed for serial links, not ethernet-like
|
||||
medium, it seems.
|
||||
- You can change compression ratio on outbound packet, by changing
|
||||
|
|
|
|||
Loading…
Reference in New Issue