On 11 Feb 2009, at 18:46, Suresh Krishnan wrote:
Section 5.1 : Option format
The alignment requirement for this option should be 4n+2 and not 4n as
mentioned in the document. This is required to align the CALIPSO DOI
on
its natural 32 bit boundary.
First, please let me note that I am not religious about this.
Users are concerned about throughput lost due to overhead.[1] This
option is already potentially large (example: when the bitmap field
is large). Packets with this option are known to be used routinely
over lower bandwidth links (e.g. IP over 2.4 Kbps HF radio) where
2 bytes might matter. Ordinary IPv6 is already operationally
challenging on such links (even with header compression), but
those link types are not going away (in fact, HF radio deployment
reportedly is growing these days, after a reported decline in
IP/HF deployments in the late 1990s).
So I can better understand your inputs, it would help to have
a bit of context:
- Are you implementing this option ?
- Do you have a MLS network deployment ?
Given the above, do you view the alignment question as a
show-stopper ?
Or can you live with the current alignment given the
very limited use of this option ?
Section 5.1.7 : CALIPSO Checksum
I do not see the real need for this option. I see two cases where the
calipso option will be secured.
I assume you meant "Checksum field" above where you wrote "option".
The Checksum is present to provide integrity, not authentication.
As noted previously, IP packets containing this option are sent
routinely over low-bandwidth lossy radio links. To be clear,
the links at issue are NOT mobile telephony links like GSM/LTE,
but instead military/emergency-service HF or VHF/UHF radio links.
IPv4 contains a header checksum that covers the existing MLS
label option(s). Of course, IPv6 does not have a header checksum.
So the MLS users wanted to be sure that this option provided
its own integrity protection mechanism. [more discussion below]
AH is present -> AH will detect the tampering as it covers the CALIPSO
option
Indeed, if used, AH would provide strong integrity and also
would provide authentication.
However, as the I-D notes already, operational experience with
existing IPv4 MLS deployments indicates that it is not
operationally viable to routinely use AH (or AH+ESP) end-to-end
to provide authentication & integrity to labelled MLS IP packets.
Since IPv6 IPsec and IPv4 IPsec areidentical, moving to IPv6
does not eliminate the operational issues (examples: crypto
processing overhead, key/SA management complexity) that impede
widespread use of AH (or ESP+AH) in MLS labelled network
deployments.
AH is not present -> Attacker can tamper with the option and then
recalculate the checkum and insert in the option
The checksum is present to improve the integrity of the option,
not to provide authentication. Indeed, the selected checksum
is intentionally easy to compute, because users want the
checksum to always be present. Implementers strongly preferred
to use an existing checksum that is not overly burdensome
computationally.
Requiring the checksum in all cases:
(1) simplifies software implementations slightly, but also
simplifies the Verilog for a (potential future)
hardware implementation of this option, [2]
(2) is not a significant computational burden for software
implementations and has even less impact on (potential)
hardware implementations of this option,
and
(3) makes the MLS user community happy.
Section 9.2 IANA considerations
Please look at the -07 version of the draft, which was just
released late last week. The IANA Considerations were
rewritten to completely follow inputs from an IESG member.
* This text
"DOI values beginning with decimal 0:0:0 are reserved for
private use amongst consenting parties; values in this range"
does not match up with the initial values table above that reserves
the
range 0:0:0:1 to 0:255:255:255
That's a typo, but a very good catch. The -07 version likely
has the same typo, which I will fix.
Thanks very much !
Yours,
Ran Atkinson
[email protected]
[1] More user input and review has happened on this I-D over the
past couple of years than I initially had expected. I've had
user inputs from a wide range of countries beyond North America
-- multiple users in Europe and multiple users in Asia have
provided very helpful review and input.
[2] As other notes to the IPv6 list indicate, the specification
has been reviewed by, and is acceptable to, multiple actual
implementers of this proposed label option. As those folks
also have implementations of the IPv4 label option(s), their
inputs have been highly valuable. The specification has
also been reviewed by a specialist "packet processing"
Verilog designer in the UK; he also is fine with the current
specification in the I-D.
EOF
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
