UDP Encapsulation of IPsec ESP Packets
draft-ietf-ipsec-udp-encaps-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Thomas Narten |
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Bert Wijnen |
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Margaret Wasserman |
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Jon Peterson |
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the Abstain position for Ted Hardie |
2004-08-10
|
09 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2004-08-10
|
09 | Amy Vezza | IESG state changed to Approved-announcement sent |
2004-08-10
|
09 | Amy Vezza | IESG has approved the document |
2004-08-10
|
09 | Amy Vezza | Closed "Approve" ballot |
2004-08-10
|
09 | Russ Housley | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Russ Housley |
2004-08-09
|
09 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to Abstain from Discuss by Ted Hardie |
2004-08-08
|
09 | Margaret Cullen | [Ballot Position Update] Position for Margaret Wasserman has been changed to No Objection from Discuss by Margaret Wasserman |
2004-07-29
|
09 | Thomas Narten | [Ballot Position Update] Position for Thomas Narten has been changed to No Objection from Discuss by Thomas Narten |
2004-05-27
|
09 | Jon Peterson | [Ballot Position Update] Position for Jon Peterson has been changed to No Objection from Discuss by Jon Peterson |
2004-05-26
|
09 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Discuss by Bert Wijnen |
2004-05-05
|
09 | (System) | New version available: draft-ietf-ipsec-udp-encaps-09.txt |
2004-04-03
|
09 | (System) | Removed from agenda for telechat - 2004-04-02 |
2004-04-02
|
09 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2004-04-02
|
09 | Russ Housley | 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 … 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. |
2004-04-01
|
09 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens |
2004-04-01
|
09 | Harald Alvestrand | 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 … 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. |
2004-04-01
|
09 | Harald Alvestrand | [Ballot comment] Reviewed by Scott Brim, Gen-ART. Comments (editorial) to tracker log. Non-blocking. |
2004-03-30
|
09 | Scott Hollenbeck | [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck |
2004-03-24
|
09 | Russ Housley | Placed on agenda for telechat - 2004-04-02 by Russ Housley |
2004-03-23
|
09 | Russ Housley | State Changes to IESG Evaluation from IESG Evaluation::Revised ID Needed by Russ Housley |
2004-02-17
|
08 | (System) | New version available: draft-ietf-ipsec-udp-encaps-08.txt |
2003-12-19
|
09 | Russ Housley | [Ballot comment] Comments from Rob Austein: > > 1) some of the weirdest stuff in this doc is due to the attempt to > … [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. |
2003-12-18
|
09 | Amy Vezza | Removed from agenda for telechat - 2003-12-18 by Amy Vezza |
2003-12-18
|
09 | Margaret Cullen | [Ballot discuss] I have three issues with this document: (1) Although the document claims that it will work for both IPv4 and IPv6, … [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. |
2003-12-18
|
09 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2003-12-18
|
09 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for by Amy Vezza |
2003-12-18
|
09 | Allison Mankin | [Ballot Position Update] New position, No Objection, has been recorded for by Allison Mankin |
2003-12-18
|
09 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for by Alex Zinin |
2003-12-18
|
09 | Bill Fenner | [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 … [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. |
2003-12-18
|
09 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for by Bill Fenner |
2003-12-18
|
09 | Thomas Narten | [Ballot comment] > The UDP header is a standard [RFC 768] header, where > - Source Port and Destination Port MUST be the … [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) > ?? |
2003-12-18
|
09 | Thomas Narten | [Ballot discuss] > A peer MAY send a NAT-keepalive packet if there exists one > or more phase I or phase II SAs between the … [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 |
2003-12-18
|
09 | Thomas Narten | [Ballot Position Update] New position, Discuss, has been recorded for by Thomas Narten |
2003-12-18
|
09 | Bert Wijnen | [Ballot comment] Comments from OPS DIrectorate (Pekka): - note that some sections like 1, 5, and 10 are indented "properly", a couple of … [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! |
2003-12-18
|
09 | Bert Wijnen | [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. … [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. |
2003-12-18
|
09 | Bert Wijnen | [Ballot Position Update] New position, Discuss, has been recorded for by Bert Wijnen |
2003-12-18
|
09 | Jon Peterson | [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 … [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. |
2003-12-18
|
09 | Jon Peterson | [Ballot Position Update] New position, Discuss, has been recorded for by Jon Peterson |
2003-12-17
|
09 | Margaret Cullen | [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 … [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. |
2003-12-17
|
09 | Margaret Cullen | [Ballot Position Update] New position, Discuss, has been recorded for by Margaret Wasserman |
2003-12-16
|
09 | Ted Hardie | [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 … [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). |
2003-12-16
|
09 | Ted Hardie | [Ballot Position Update] New position, Discuss, has been recorded for by Ted Hardie |
2003-12-16
|
09 | Steven Bellovin | [Ballot comment] Is the v4-only orientation enough of a problem here that we should send this back? |
2003-12-16
|
09 | Steven Bellovin | [Ballot Position Update] New position, No Objection, has been recorded for by Steve Bellovin |
2003-12-05
|
09 | Ned Freed | [Ballot comment] Nits: No copyright boilerplate No IPR boilerplate |
2003-12-05
|
09 | Ned Freed | [Ballot Position Update] New position, No Objection, has been recorded for by Ned Freed |
2003-12-04
|
09 | Russ Housley | Status date has been changed to 2003-12-04 from 2003-11-09 |
2003-12-04
|
09 | Russ Housley | Placed on agenda for telechat - 2003-12-18 by Russ Housley |
2003-12-04
|
09 | Russ Housley | [Ballot Position Update] New position, Yes, has been recorded for Russ Housley |
2003-12-04
|
09 | Russ Housley | Ballot has been issued by Russ Housley |
2003-12-04
|
09 | Russ Housley | Created "Approve" ballot |
2003-12-04
|
09 | Russ Housley | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Russ Housley |
2003-12-03
|
09 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2003-11-19
|
09 | Amy Vezza | Last call sent |
2003-11-19
|
09 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2003-11-19
|
09 | Russ Housley | Last Call was requested by Russ Housley |
2003-11-19
|
09 | Russ Housley | State Changes to Last Call Requested from Waiting for AD Go-Ahead::Revised ID Needed by Russ Housley |
2003-11-18
|
07 | (System) | New version available: draft-ietf-ipsec-udp-encaps-07.txt |
2003-11-09
|
09 | Russ Housley | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Russ Housley |
2003-11-09
|
09 | Russ Housley | Status date has been changed to 2003-11-09 from 2003-10-08 |
2003-11-04
|
09 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2003-10-21
|
09 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2003-10-20
|
09 | Russ Housley | Last Call was requested by Russ Housley |
2003-10-20
|
09 | Russ Housley | State Changes to Last Call Requested from Last Call Requested by Russ Housley |
2003-10-20
|
09 | (System) | Ballot writeup text was added |
2003-10-20
|
09 | (System) | Last call text was added |
2003-10-20
|
09 | (System) | Ballot approval text was added |
2003-10-09
|
09 | Russ Housley | State Changes to Last Call Requested from AD Evaluation::Revised ID Needed by Russ Housley |
2003-10-08
|
09 | Russ Housley | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Russ Housley |
2003-10-08
|
09 | Russ Housley | Status date has been changed to 2003-10-08 from 2003-05-30 |
2003-06-06
|
09 | Russ Housley | State Changes to AD Evaluation from Publication Requested by Housley, Russ |
2003-05-30
|
09 | Russ Housley | Draft Added by Housley, Russ |
2003-01-14
|
06 | (System) | New version available: draft-ietf-ipsec-udp-encaps-06.txt |
2002-12-20
|
05 | (System) | New version available: draft-ietf-ipsec-udp-encaps-05.txt |
2002-11-05
|
04 | (System) | New version available: draft-ietf-ipsec-udp-encaps-04.txt |
2002-07-26
|
(System) | Posted related IPR disclosure: Microsoft's Patent Claim pertaining to draft-ietf-ipsec-nat-t-ike and draft-ietf-ipsec-udp-encaps | |
2002-06-12
|
03 | (System) | New version available: draft-ietf-ipsec-udp-encaps-03.txt |
2002-04-19
|
02 | (System) | New version available: draft-ietf-ipsec-udp-encaps-02.txt |
2001-10-03
|
01 | (System) | New version available: draft-ietf-ipsec-udp-encaps-01.txt |
2001-06-21
|
00 | (System) | New version available: draft-ietf-ipsec-udp-encaps-00.txt |