Re: Last Call: 'UDP Encapsulation of IPsec Packets' to Proposed Standard

[Erik Nordmark <Erik.Nordmark@sun.com>]

[Not copying the ipsec list since I don't know how contentious the IPR
issue has been. 1 and 2 could be shared with them without a fear of
revisiting a potential IPR rathole.]

Three issues:

1. Document says:
    UDP encapsulation of ESP packets as defined in this document is
    written in terms of IPv4 headers. There is no technical reason
    why an IPv6 header could not be used as the outer header and/or
    as the inner header.
and then
   - Checksum SHOULD be transmitted as a zero value.

Alas UDP checksum is not optional in IPv6 and a checksum value of zero for
UDP is not allowed (per RFC 2460 the receiver must discard packets with
a zero UDP checksum.) 
Needs to be fixed.


2. This text in section 3.1.2 can be misread (I had to read it 3 times myself):
c) If the protocol header after the ESP header is an UDP
    header, zero the checksum field in the UDP header. If the protocol
    header after the ESP header is a TCP header, and there is an
    option to flag to the stack that TCP checksum does not need to
    be computed, then that flag MAY be used.  This SHOULD only be done
    for transport mode, and if the packet is integrity protected.  Tunnel
    mode TCP checksums MUST be verified.
    [This is not a violation to the spirit of section 4.2.2.7 in RFC 1122
    because a checksum is being generated by the sender, and verified
    by the receiver.  That checksum is the integrity over the packet
    performed by IPsec.]
If this is read out of context and with the weakness in the "This" in "This
SHOULD only ..." (does "this" refer to the TCP aspect? all of the above?)
one could easily think that UDP checksum can be zeroed for tunnel mode
(even though the section is only about transport mode).
This coupled with UDP checksum of zero not being allowed for IPv6 makes
things worse.
One way to make this more clear is to *describe* the UDP case the same
as the TCP case i.e. if there is a local implementation mechanism to
flag to TCP/UDP that their checksum has already been verified, then that
mechanism may be used.
Something like:
  c) If there is a local implementation mechanism (flag) to
     flag to TCP/UDP that their checksum have already been verified, if
     the protocol header after the ESP header is a TCP header or a UDP header,
     and if the packet is integrity protected by ESP, than that flag MAY be
used.
    [This is not a violation to the spirit of section 4.2.2.7 in RFC 1122
    because a checksum is being generated by the sender, and verified
    by the receiver.  That checksum is the integrity over the packet
    performed by IPsec.]


3. IPR

I note that the IPR notification at ietf.org basically says that
a license is needed, it is royalty-free with other reasonable and 
non-discriminatory requirements.

Would a lawyer think that any of these are unreasonable?
 - give due credit to the IPR holder on all documentation and software,
 - hold the implementation of the patent as proprietary information

Either one (and even the explicit licensing requirement) could make
open source implementation hard to impossible.

Has this been discussed in the WG?
FWIW I note that some vendors have started using "not assert any claims
based on receiprocity" which IMHO is a lot friendlier to open source.

  Erik