UDP Encapsulation of IPsec ESP Packets
RFC 3948

Note: This ballot was opened for revision 09 and is now closed.

(Russ Housley) Yes

Comment (2003-12-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Comments from Rob Austein:
> 
> 1) some of the weirdest stuff in this doc is due to the attempt to
>    support a mutant form of transport mode.   limiting the goals to
>    tunnel mode would simplify things considerably.
> 
> 2) leaving (1) aside for the moment, margaret is correct about the
>    problems with their checksum handwaving.  unless the encapsulator
>    verifies the checksum, there's nothing to protect packet integrity
>    from originator to encapsulator.  even if the encapsulator does
>    verify the checksum, it's still not end to end anymore, so data is
>    subject to undetectable corruption if the encasulator is broken.
>    basicly, this is the old "stuck bit on the router" problem.
> 
> 3) piggybacking all this on the ike port is pretty sick.
> 
> 4) overall, it sure seems like a minimal thing that just did tunnel
>    mode over udp to a well-known destination port and didn't try to do
>    anything more complicated (well, it might need a nat keepalive
>    probe) would be a lot less problematic.
> 
> maybe all of this is justifiable and it's just not in the doc, but
> color me skeptical.

(Harald Alvestrand) No Objection

Comment (2004-04-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Reviewed by Scott Brim, Gen-ART.

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

(Steven Bellovin) No Objection

Comment (2003-12-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Is the v4-only orientation enough of a problem here that we should send this back?

(Margaret Cullen) (was Discuss) No Objection

(Bill Fenner) No Objection

Comment (2003-12-18 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Ned Freed) No Objection

Comment (2003-12-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Nits:

No copyright boilerplate
No IPR boilerplate

(Scott Hollenbeck) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

(Thomas Narten) (was Discuss) No Objection

Comment (2003-12-18)
No email
send info
> 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>

??

(Jon Peterson) (was Discuss) No Objection

(Bert Wijnen) (was Discuss) No Objection

Comment (2003-12-18)
No email
send info
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!

(Alex Zinin) No Objection

(Ted Hardie) (was Discuss) Abstain