UDP Encapsulation of IPsec ESP Packets
draft-ietf-ipsec-udp-encaps-09

Comments from OPS DIrectorate (Pekka):

  
- note that some sections like 1, 5, and 10 are indented "properly", 
  a couple of spaces off the left margin.  The rest aren't, and are less 
  readable.  It would be very nice to get this to be coherent.

- may want to use rfc2119 langauge:

  The SPI field in the ESP header must not be zero.

  s/must not/MUST NOT/ ?

- Questions on IANA considerations:

  6. IANA Considerations
                                                
     No IANA assignments are needed.
                                                                                                                                       
     This document depends on the reserved SPI value of zero (0) not
     being sent over the wire as a part of an ESP-packet [RFC 2406].
                                                 
     This document defines a "Non-ESP Marker" as 4 bytes of zero aligning
     with the SPI field of an ESP packet, and generally being followed
     by something that is not an ESP packet.
                                                       
     With regard to NAT-traversal in IKEv1 case, the Non-ESP Marker is
     being followed by an IKEv1 packet as specified in section 2.2.

  what do the last three paragraphs have to do with IANA 
  considerations section?  They're probably useful, but move them 
  somewhere else!

Call me "no further objection" - however, the NAT keepalive time reminds me that we saw (approved? I don't remember) a document that had similar NAT keepalive requirements and suggested some specifics; it may be worth figuring out what we had suggested there to try to be consistent.  Sorry this is vague, I'll try to figure out what I'm remembering.

Reviewed by Scott Brim, Gen-ART.

Comments (editorial) to tracker log. Non-blocking.

Nits:

No copyright boilerplate
No IPR boilerplate

Is the v4-only orientation enough of a problem here that we should send this back?

> The UDP header is a standard [RFC 768] header, where
> - Source Port and Destination Port MUST be the same as used by
>    IKE traffic.
> - Checksum SHOULD be transmitted as a zero value.
> - Receivers MUST NOT depend upon the UDP checksum being
>    a zero value.

UDP checksum can't be 0 in IPv6.

> In addition an implementation MAY fix any contained protocols that
> have been broken by NAT.

Not clear this sentence is really appropriate  here. This is a true
statement for a NAT box for sure, but _this_ document is specifically
about  IKE traversal, not other protocols.

>     Implementors are warned that it is possible for remote peers to
>     negotiate entries that overlap in a GW, an issue affecting tunnel
>     mode.

GW used before defined.

>     It is RECOMMENDED that GW either assign locally unique IP addresses
>     to A and B using a protocol such as DHCP over IPsec, or uses NAT to
>     change A's and B's source IP addresses to such locally unique
>     addresses before sending packets forward to S.

what are A, B and S? (use consistent names)

> </x-flowed>

??