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

Many Area Directors feel that their comments were not addressed in the updated draft.  I have asked the authors to generate a message to the IESG that explains how each of the comments are handled.  Once this is received, I suggest a teleconference with the authors and the ADs that hold DISCUSS positions.  Hopefully this can happen quickly, and it will resolve the remaining open issues.

From Scott Brim, Gen-ART:

Good but there are a few nits.  The content is fine, but ...

References need to be updated, e.g. Aboda03 is now RFC3715.  In any case
There are some issues, mostly small.  I don't know if I would even say
it's on the right track.  See Rob Austein's comment about whether
carrying all of this over IKE is architecturally sane.

It still doesn't seem to address the IPv6 differences explicitly.  It
just says there is "no reason why not". 
specific sections in other documents were accurate, but if they have the
name wrong, I'd be suspicious.

"2.2 IKE Header Format for Port 4500" -- I know what this is about, but
the use of Port 4500 is not mentioned before this. 

On page 7:

  2.  If the protocol header after the ESP header is a TCP/UDP header,
      recompute the checksum field in the TCP/UDP header.

  3.  If the protocol header after the ESP header is an UDP header,
      zero the checksum field in the UDP header. If the protocol header
      ...

#3 is actually the details of #2.  Perhaps it should be a sub-bullet.

[Ballot comment]
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.

[Ballot discuss]
I have three issues with this document:

(1) Although the document claims that it will work for both
    IPv4 and IPv6, it is not correct for IPv6.  There is no
    IP header checksum in IPv6 and UDP checksums cannot be
    turned off by setting them to zero.

(2) Instead of choosing a single way that the packets will
    be encapsulated/decapsulated, a lot of options are left
    to "policy".  Is the assumption that both ends of the   
    connection will be under the same administrative control
    and have consistent policy?  This reliance on policy would
    seem to limit open interoperability.

(2) This document is very difficult to understand.  I still
    don't understand, for instance, whether this mechanism
    is only intended to work when the UDP header is added
    by the sender and removed by the final receiver, or
    whether there could be a UDP/IP tunnel across the NAT,
    and the end-points could be unaware of it.  A real
    introduction that describes the proposed solution and
    introduces terminology for the various nodes involved
    would help.  Examples might also help.  As-is, I am not
    certain that I would understand how to implement this
    specification.

[Ballot comment]
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.

[Ballot comment]
> 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)

>

??

[Ballot discuss]
> A peer MAY send a NAT-keepalive packet if there exists one
> or more phase I or phase II SAs between the peers, or such

seem like MAY should be a SHOULD (things just won't work
otherwise). Also, this is tricky stuff, and the recommendation of
defaulting to once every 5 minutes seems inadequate. Some relevant
discussion on the topic can be found in section 3.1 of
draft-huitema-v6ops-teredo-00.txt.

> 5.1 Denial of Service
>
>    On some systems ESPUDP may have DoS attack consequences,
>    especially if ordinary operating system UDP-functionality is
>    being used. It is RECOMMENDED that the UDP packets be processed
>    by a system component that does the strictest possible checks
>    for UDP packets.

Please explain further (too much left as an exercise to the
reader). Or cite some other document that explains this in more detail?

> Generic choices for ESP transport mode:
> Tr1) Implement a built-in NAT (network address translation) above IPsec
> decapsulation.  SSH may have intellectual property rights relating to
> this implementation technique.  See their IPR notice on the IETF web
> site for the details.

In correct IPR reference on SSH.

> Tr2) Implement a built-in NAPT (network address port translation) above
> IPsec decapsulation. Microsoft may have intellectual property rights
> relating to this implementation technique.  See the Microsoft IPR notice
> on the IETF web site for the details.

ditto

[Ballot comment]
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!

[Ballot discuss]
Isuses raised by OPS Directorate (Pekka)

I have serious issues with this one.  It just doesn't appear to be
ready at this point.

As a high-level comment, this document seems to specify how to use ESP
with all the possible ways through the NAT.  My knee-jerk reaction is,
why not use IPv6 instead of fussing with all of the NAT traversal
mechanisms?  If this is really needed, would it be possible to specify
just *one* encapsulation method (e.g. tunnel mode ESP), for the most
generic case (VPNs ?), for simplicity.

Well, maybe this isn't the arena to wrestle this..

Another high-level comment: does it make sense to overload the IKE
port 500 (used for *signalling plane*) to be used for data
encapsulation (*data plane*)?  Has this been explicitly discussed? 
This has it's pros and cons, of course.. but this is an issue with may
have a large number of implications.  Even if so, maybe some more
discussion on why this is good/bad idea should be included in the
document.

As for the details, this specification appears to be half-baked, for
many reasons (I didn't read it in detail, but four seemed apparent
right out):

1) The title states "IPsec packets" but the specification only
includes ESP.  Of course, AH is not really that interesting, but *at
least* there should be a paragraph in the Introduction or so if it's
left out.

2) The wordings in many places in the draft assume that IKE has been
used, and some information learnt using IKE is being used for the
encapsulation/decapsulation.  This seems like an implicit assumption
-- either one should spell out that this mechanism only works with
IKE, or use different wordings which are OK with also manual keying.

3) The document refers to "IKE" in many places, and in every place
except one of them, there is no distinction made whether we're talking
about IKEv1 or the upcoming IKEv2.  The applicability should be
clearer; this could maybe also be fixed in the Introduction if the
method only applies to IKEv1.  If it's meant to apply to IKEv2 as
well, is some more specification needed?

4) The appendix lists several implementation techniques and whether
there are some IPR and by whom.  This is a bad practice as it may make
the reader think that those are the only IPR issues related to the
specification.  At least reword like s/SSH may have../At least, SSH
may have/, and s/their IPR notice/the IPR notices/.  See below for an
example (there are numerous other ones):

Generic choices for ESP transport mode:
Tr1) Implement a built-in NAT (network address translation) above
IPsec decapsulation.  SSH may have intellectual property rights
relating to this implementation technique.  See their IPR notice on
the IETF web site for the details.

.. also, the IPR section (7. at the moment) should also include the
boilerplate(s) and such.


Bert adds:
There should be a standard IPR section as we know it.
Talk about specific IPR considerations of different mechanims should
probably NOT be done in this document itself, but by submissions of claims
to the IETF Executive Director.

[Ballot discuss]
Like another IPsec-related NAT document we recently reviewed, this document contains no UNSAF considerations (i.e. it should explictly answer the questions given in RFC3424 Section 4). For a good example of UNSAF considerations, see RFC3489.

Also, the account of NATs given in this document does not refer to the different types of NATs (see RFC3489 Section 5 for a taxonomy of NATs). For what sorts of NATs is this mechanism intended to be useful?

The motivation for encapsulating with UDP (as opposed to any transport protocol) also doesn't seem to be described by the document. UDP, because it is not connection oriented, creates special difficulties for NAT traversal - NATs have no way of determining the start or stop of flows, and accordingly, many NAT implementations expire UDP bindings very quickly. While I appreciate that there are probably very good reasons to use UDP as opposed to some connection-oriented transport protocol, I think those reasons should be explicitly stated.

From Section 3.1.2, one gathers that TCP may be used over ESP encapsulated within UDP. While the section revises checksum calculation for encapsulated TCP in some detail, it doesn't discuss any other processing associated with the TCP stack - window management, congestion control, etc. Some text that at least states that TCP should in other respects behave normally when encapsulated over UDP would be nice.

[Ballot discuss]
There are a number of problems in this draft.  Among other things,
it claims to apply to both IPv4 and IPv6, but it suggests some
things that won't work in IPv6 (such as setting the UDP checksum
to zero)...

The draft is also terse enough that parts of it are hard to
understand.

I will generate a more complete set of issues Thursday afternoon
and enter them here.

[Ballot discuss]
5.2 and 5. 3 of the draft punt hard problems to Appendix A, which then says "not a wire protocol, so this is just a suggestion".  The hard question of whether the Internet can support a wire protocol that doesn't have those hard problems solved issues is thus neatly avoided.

The fundamental problem here is that this mechanism can leave which SA is to be associated with some of the traffic unclear.  Having some default mechanism to handle that be clear (and not have the potential IPR buried in the Appendix) seems reasonable. 

As a point of clarification, in 5.2, the Draft says:

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.

A and B are not referenced in the text above, and that should be fixed.
Suggesting an additional NAT in the gateway (rather than NAPT) seems
like it prefers one party's IPR over another's (see TR1 and TR2 in the Appendix).