TCP Encapsulation of IKE and IPsec Packets
draft-ietf-ipsecme-tcp-encaps-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-08-09
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-08-01
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2017-07-18
|
10 | Tero Kivinen | Added to session: IETF-99: ipsecme Fri-1150 |
2017-07-14
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2017-06-27
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2017-06-27
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2017-06-20
|
10 | (System) | RFC Editor state changed to EDIT |
2017-06-20
|
10 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-06-20
|
10 | (System) | Announcement was received by RFC Editor |
2017-06-19
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2017-06-19
|
10 | (System) | IANA Action state changed to In Progress |
2017-06-19
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2017-06-19
|
10 | Amy Vezza | IESG has approved the document |
2017-06-19
|
10 | Amy Vezza | Closed "Approve" ballot |
2017-06-19
|
10 | Amy Vezza | Ballot approval text was generated |
2017-06-17
|
10 | Eric Rescorla | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2017-06-14
|
10 | Mirja Kühlewind | [Ballot comment] Thanks for addressing my discuss. I've only checked the diff but that seems fine now :-) Two more tiny things that I would … [Ballot comment] Thanks for addressing my discuss. I've only checked the diff but that seems fine now :-) Two more tiny things that I would recommend to change but can be done by the RFC editor: OLD "Implementations SHOULD favor using direct ESP or UDP encapsulation over TCP encapsulation whenever possible." NEW "Implementations SHOULD use direct ESP or UDP encapsulation over TCP encapsulation whenever possible." OLD "TCP Responders should be careful to ensure that the stream prefix "IKETCP" uniquely identifies incoming streams as ones that use the TCP encapsulation protocol, and they are not running any other protocols on the same listening port that could conflict with this." NEW "TCP Responders should be careful to ensure that the stream prefix "IKETCP" uniquely identifies incoming streams as ones that use the TCP encapsulation protocol, and MUST not run any other protocols on the same listening port that could conflict with this." |
2017-06-14
|
10 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2017-06-14
|
10 | Mirja Kühlewind | [Ballot Position Update] Position for Mirja Kühlewind has been changed to No Objection from Discuss |
2017-06-14
|
10 | Mirja Kühlewind | [Ballot comment] Thanks for addressing my discuss. I've only checked the diff but that seems fine now :-) Two more tiny things that I would … [Ballot comment] Thanks for addressing my discuss. I've only checked the diff but that seems fine now :-) Two more tiny things that I would recommend to change but can be done by the RFC editor: OLD "Implementations SHOULD favor using direct ESP or UDP encapsulation over TCP encapsulation whenever possible." NEW "Implementations SHOULD use direct ESP or UDP encapsulation over TCP encapsulation whenever possible." OLD "TCP Responders should be careful to ensure that the stream prefix "IKETCP" uniquely identifies incoming streams as ones that use the TCP encapsulation protocol, and they are not running any other protocols on the same listening port that could conflict with this." NEW "TCP Responders should be careful to ensure that the stream prefix "IKETCP" uniquely identifies incoming streams as ones that use the TCP encapsulation protocol, and MUST not run any other protocols on the same listening port that could conflict with this." |
2017-06-14
|
10 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2017-05-31
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2017-05-31
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2017-05-31
|
10 | Tommy Pauly | New version available: draft-ietf-ipsecme-tcp-encaps-10.txt |
2017-05-31
|
10 | (System) | New version approved |
2017-05-31
|
10 | (System) | Request for posting confirmation emailed to previous authors: Samy Touati , Tommy Pauly , Ravi Mantha |
2017-05-31
|
10 | Tommy Pauly | Uploaded new revision |
2017-05-04
|
09 | Tero Kivinen | Closed request for Telechat review by SECDIR with state 'No Response' |
2017-04-27
|
09 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for Writeup |
2017-04-27
|
09 | Benoît Claise | [Ballot comment] Just sharing some random thoughts. No action is needed here. Most implementations should use TCP Encapsulation only on networks where negotiation … [Ballot comment] Just sharing some random thoughts. No action is needed here. Most implementations should use TCP Encapsulation only on networks where negotiation over UDP has been attempted without receiving responses from the peer, or if a network is known to not support UDP. On one side, some companies deny IKE/IPSEC on purpose. In the future, they will just block port 4500. This document leaves the selection of TCP ports up to implementations. It is suggested to use TCP port 4500, which is allocated for IPsec NAT Traversal. Well, if any port can be used, that becomes difficult. On the other hand, just is like any tunneling mechanisms, which exist for some time already. QoS within TCP will be a real operational issues, as inner to outer ToS mapping is not possible. |
2017-04-27
|
09 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2017-04-26
|
09 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2017-04-26
|
09 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2017-04-26
|
09 | Alia Atlas | [Ballot Position Update] Position for Alia Atlas has been changed to No Objection from No Record |
2017-04-26
|
09 | Spencer Dawkins | [Ballot comment] I support Mirja's Discuss, and am happy with the direction that discussing is headed. |
2017-04-26
|
09 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-04-26
|
09 | Ben Campbell | [Ballot comment] Update: Thanks for proposing text to address my DISCUSS point. I've cleared the discuss, with the assumption the proposed edit (or similar) will … [Ballot comment] Update: Thanks for proposing text to address my DISCUSS point. I've cleared the discuss, with the assumption the proposed edit (or similar) will make it into the draft. Substantive Comments: -2: -- 2nd bullet (and elsewhere) I think this needs a discussion about how those configured ports are likely to be in the assigned range, and the likely impact. (I recognize that tunneling over a port assigned to something else is a primary reason for doing this. I'm not arguing against it; I just think the implications warrant discussion.) -- 2nd to last paragraph: "This document leaves the selection of TCP ports up to implementations." I suspect "configurable local policy" would make more sense. Leaving it up to "implementations" leaves open the chance of different implementations making non-intersecting port choices, which doesn't help interoperability. -3, first paragraph: Are people confident there will never, ever be a need to demux protocols other than IKE and ESP? If not, this approach may paint people in a corner in the future. I ask because we made similar choices with DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an issue. See RFC7983 for a discussion. (Note that this would have been a DISCUSS point, but I think it's reasonably likely that there really won't be other protocols here. But I want to make sure people have thought about it.) -4, first paragraph: What is the expected behavior from a peers that do not support this spec when they receive a TCP stream with the magic number on a port for some other protocol? -6: First paragraph: It would be helpful to mention behavior on receipt of a stream without the magic number here. But see the DISCUSS point. -8: "... MUST support dynamically enabling and disabling TCP encapsulation..." seems unreasonably strong, especially since the requirement to try UDP before TCP is only a SHOULD. Does this contemplate situations where it might be impossible to use TCP on the after a network change? - Appendix A: Doesn't the use of the NULL cipher invalidate one of the primary reasons to use TLS? (Namely to obscure the fact that this is not HTTP, or whatever other protocol is assigned to the port?) Editorial Comments: - Please expand IKE and ESP on first mention in both the abstract and body. -3, 2nd paragraph: s/"may be able"/"is able". -3.2, " The SPI field in the ESP header MUST NOT be a zero value." Is this a new requirement for this draft? That is, does ESP otherwise allow zero value SPIs? If not, please consider dropping the MUST NOT. -5.1: "...SHOULD always attempt negotiate IKE over UDP first" This is stated several times in the draft, more than once with the SHOULD. It's better to avoid redundant 2119 keywords. -6: "... IKE Figure 1 and ESP Figure 2... ": Broken section cross-references. -10, title: Please expand DPD. -12: Several previous sections pointed to section 12 for more information about why one needed to try direct connections or UDP before TCP. But I don't find any specifics on that in this section. - Appendix A: Why is this an appendix? It contains normative text that seems central to certain use cases. I was surprised to see no discussion about using TLS in section 11, where it seemed quite relevant. |
2017-04-26
|
09 | Ben Campbell | [Ballot Position Update] Position for Ben Campbell has been changed to No Objection from Discuss |
2017-04-26
|
09 | Alia Atlas | [Ballot comment] I agree with Mirja's discuss. |
2017-04-26
|
09 | Alia Atlas | Ballot comment text updated for Alia Atlas |
2017-04-26
|
09 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2017-04-26
|
09 | Alexey Melnikov | [Ballot comment] 2. Configuration o Optionally, an extra framing protocol to use on top of TCP to further encapsulate the stream … [Ballot comment] 2. Configuration o Optionally, an extra framing protocol to use on top of TCP to further encapsulate the stream of IKE and IPsec packets. See Appendix A for a detailed discussion. As Appendix A just talks about TLS, why not say this here explicitly? The sentence above make it sound like this is something outside of scope for the document and Appendix A talks about generic way to encapsulate. |
2017-04-26
|
09 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2017-04-25
|
09 | Ben Campbell | [Ballot discuss] I have one (hopefully easy) point that I think needs to be fixed before progressing. Section 6, paragraph 6 says : "... if … [Ballot discuss] I have one (hopefully easy) point that I think needs to be fixed before progressing. Section 6, paragraph 6 says : "... if the TCP Originator stream is missing the stream prefix, or message frames are not parsable as IKE or ESP messages), it MUST close the TCP connection." IIUC, the entire point of having the stream prefix is to allow the TCP responder to demux between this protocol, and some other protocol that would normally run on that port. Saying it MUST close the TCP session seems to completely remove that value. I assume people meant to allow the respondent to delegate a stream out to some other protocol handler if the prefix is not present? |
2017-04-25
|
09 | Ben Campbell | [Ballot comment] Substantive Comments: -2: -- 2nd bullet (and elsewhere) I think this needs a discussion about how those configured ports are likely to be … [Ballot comment] Substantive Comments: -2: -- 2nd bullet (and elsewhere) I think this needs a discussion about how those configured ports are likely to be in the assigned range, and the likely impact. (I recognize that tunneling over a port assigned to something else is a primary reason for doing this. I'm not arguing against it; I just think the implications warrant discussion.) -- 2nd to last paragraph: "This document leaves the selection of TCP ports up to implementations." I suspect "configurable local policy" would make more sense. Leaving it up to "implementations" leaves open the chance of different implementations making non-intersecting port choices, which doesn't help interoperability. -3, first paragraph: Are people confident there will never, ever be a need to demux protocols other than IKE and ESP? If not, this approach may paint people in a corner in the future. I ask because we made similar choices with DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an issue. See RFC7983 for a discussion. (Note that this would have been a DISCUSS point, but I think it's reasonably likely that there really won't be other protocols here. But I want to make sure people have thought about it.) -4, first paragraph: What is the expected behavior from a peers that do not support this spec when they receive a TCP stream with the magic number on a port for some other protocol? -6: First paragraph: It would be helpful to mention behavior on receipt of a stream without the magic number here. But see the DISCUSS point. -8: "... MUST support dynamically enabling and disabling TCP encapsulation..." seems unreasonably strong, especially since the requirement to try UDP before TCP is only a SHOULD. Does this contemplate situations where it might be impossible to use TCP on the after a network change? - Appendix A: Doesn't the use of the NULL cipher invalidate one of the primary reasons to use TLS? (Namely to obscure the fact that this is not HTTP, or whatever other protocol is assigned to the port?) Editorial Comments: - Please expand IKE and ESP on first mention in both the abstract and body. -3, 2nd paragraph: s/"may be able"/"is able". -3.2, " The SPI field in the ESP header MUST NOT be a zero value." Is this a new requirement for this draft? That is, does ESP otherwise allow zero value SPIs? If not, please consider dropping the MUST NOT. -5.1: "...SHOULD always attempt negotiate IKE over UDP first" This is stated several times in the draft, more than once with the SHOULD. It's better to avoid redundant 2119 keywords. -6: "... IKE Figure 1 and ESP Figure 2... ": Broken section cross-references. -10, title: Please expand DPD. -12: Several previous sections pointed to section 12 for more information about why one needed to try direct connections or UDP before TCP. But I don't find any specifics on that in this section. - Appendix A: Why is this an appendix? It contains normative text that seems central to certain use cases. I was surprised to see no discussion about using TLS in section 11, where it seemed quite relevant. |
2017-04-25
|
09 | Ben Campbell | [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell |
2017-04-25
|
09 | Kathleen Moriarty | [Ballot comment] Thank you for documenting this practice to improve interoperability. This practice has been in place for a while and I think this is … [Ballot comment] Thank you for documenting this practice to improve interoperability. This practice has been in place for a while and I think this is a helpful document. I have a few comments. I think it would be good for the introduction to be more explicit on where the problem lies that has resulted in this common practice of tunneling this traffic through TCP. The following sentence could be modified: OLD: Many network middleboxes that filter traffic on public hotspots block all UDP traffic, including IKE and IPsec, but allow TCP connections through since they appear to be web traffic. NEW (or something along these lines): Many network edge middleboxes that filter traffic on public hotspots block all UDP traffic, including IKE and IPsec, but allow TCP connections through since they appear to be web traffic. I think it's important to note that this is happening at the edge in case that is not clear enough with the phrase "public hotspots". If it's more than the edge where this is happening, and I'm not right about this suggested change, please just say so. For section 11 - I think it's worth adding more text to hit on the concerns Warren raised in one of his comments. Here are some thoughts in case it is helpful: I agree with Warren that the result of operators not being able to identify this traffic should be mentioned, although this is tricky. The port discussion in other AD reviews and discouraging the use of 443 may change this to be identifiable traffic over TCP 4500 with the required stream prefix only for legitimate uses, or in reality, 443 if this stays undocumented because of existing implementations. Warren commented on operators not being able to detect this traffic is an important one, but I think it's fine to say the intent is to circumvent ACLs or firewall rules as opposed to avoiding detection. Then saying that avoiding detection is a result or unintended side effect. Side comment not intended for any new text: It would be good if operators observed the blocked ports (UDP 500) and figured out that they should open the port, but this has been a problem for some time and not all networks have dedicated operators (who want to fix this and similar issues) or ones with the time and skill sets to fix the problem. |
2017-04-25
|
09 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2017-04-25
|
09 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2017-04-25
|
09 | Mirja Kühlewind | [Ballot discuss] This draft suggests that ports that are assigned to other services can simply be used. This is not okay. If a port is … [Ballot discuss] This draft suggests that ports that are assigned to other services can simply be used. This is not okay. If a port is assigned to a certain service, this service and/or the respective RFC defines how this port is used. Simply changing the specified behavior by requiring a check for a magic number cannot be done without updating the RFC that the port assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as the IANA registry would need to be updated. Further, as also mentioned in the tsv-art review (Thanks Wes!), this draft does not sufficiently handle the case of TCP in TCP encapsulation. Here a copy of the tsv-art review: Reviewer: Wesley Eddy Review result: On the Right Track This document is clear and well-written. It can easily be implemented based on the description. There are a few additional issues that should be considered with advice to implementers in Section 12 on performance considerations: 1) Invisibility of packet loss - Inner protocols that require packet losses as a signal of congestion (e.g. TCP) will have a challenge due to not being able to see any packet losses since the outer TCP will repair them (unless sending into a full outer TCP socket buffer shows up back to the inner TCP as a packet loss?). 2) Nesting of ECN - Inner TCP connections will not be able to use effectively ECN on the portion of the path covered by the outer TCP connection. 3) Impact of congestion response on aggregate - The general "TCP in TCP" problem is mentioned, and is mostly appropriate for a single flow. If an aggregate of flows is sharing the same outer TCP connection, there may be additional concerns about how the congestion response behavior impacts an aggregate of flows, since it may cause a shared delay spike even to low-rate flows rather than distributing losses proportional to per-flow throughput. 4) Additional potential for bufferbloat - Since TCP does not bound latency, some applications in the IPsec-protected aggregate could drive latency of the shared connection up and impact the aggregate of flows that may include real-time applications. The socket buffer for the outer TCP connection might need to be limited in size to ensure some bounds? Not addressing these could lead to poor experiences in deployment, if implementations make wrong assumptions or fail to consider them. In the security considerations section, there are several RFCs on mechanisms to increase robustness to RST attacks and SYN floods that could be mentioned if it's worthwhile. |
2017-04-25
|
09 | Mirja Kühlewind | [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind |
2017-04-24
|
09 | Warren Kumari | [Ballot comment] Please also see Mahesh Jethanandani's OpsDir review - https://www.ietf.org /mail-archive/web/ops-dir/current/msg02602.html Having run into this issue of middle boxes blocking non-UDP/non-TCP, I think that … [Ballot comment] Please also see Mahesh Jethanandani's OpsDir review - https://www.ietf.org /mail-archive/web/ops-dir/current/msg02602.html Having run into this issue of middle boxes blocking non-UDP/non-TCP, I think that this is valuable. The document also covers a bunch of the standard operational and management considerations, and things like MTU issues, performance implications, etc.; thanks for this. One thing that I'd like to note is that this makes it significantly harder for an operator to simply block IPsec, but, well, that's kinda the point I guess... :-) I did have a number of minor questions and comments: (bikeshedding) Section 1, Bullet 2: "and ESP packets are sent out over UDP port 4500" - "sent out over" confused me (especially because ESP UDP is somewhat unusual to begin with) - perhaps "sent using UDP with source and destination port of 4500"? Section 1.2: "the role of IKE Initiator and Responder may swap for a given SA (as with IKE SA Rekeys)" -- a reference to rekeying would be good - perhaps RFC 7296 ? Section 4: The table containing "IKETCP" should be referenced (e.g: "containing the characters "IKETCP" as ASCII values (Figure 3).") Section 5: "If a Responder is configured to use TCP encapsulation, it MUST listen on the configured port(s) in case any peers will initiate new IKE sessions." s/will// (spurious will) "all of the endpoints equally support TCP encapsulation." -- what does equally" mean? All must do it, same TCP port, etc.? "MOBIKE" needs a reference. Section 11: "A network device that monitors up to the application layer will commonly expect to see HTTP traffic ..." - it might be useful to explain that this is simply an example. (the same thing happens if non-SMTP is seen on port 25, etc) |
2017-04-24
|
09 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2017-04-24
|
09 | Adam Roach | [Ballot comment] Suggest expanding "IKE" and "ESP" in the Abstract on first use. The "MUST support dynamically enabling and disabling TCP" in section 8 seems … [Ballot comment] Suggest expanding "IKE" and "ESP" in the Abstract on first use. The "MUST support dynamically enabling and disabling TCP" in section 8 seems unnecessarily strong. Every other normative statement in the document indicating the use of direct ESP or UDP encapsulation is only at a SHOULD level. This "MUST" is the sole statement that would make a TCP-only MOBIKE implementation noncompliant (rather than conditionally compliant), where non-MOBIKE implementations have no such restriction. Is that the intention? Section 12.2 claims that retransmission is a source of issues for delay-sensitive UDP applications. In practice, the retransmission is just fine; it's the head-of-line blocking that occurs upon packet loss that causes issues. Suggest stating issue in those terms. |
2017-04-24
|
09 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2017-04-24
|
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-04-24
|
09 | Eric Rescorla | [Ballot comment] I reviewed this document privately before becoming AD. |
2017-04-24
|
09 | Eric Rescorla | Ballot comment text updated for Eric Rescorla |
2017-04-24
|
09 | Eric Rescorla | Ballot has been issued |
2017-04-24
|
09 | Eric Rescorla | [Ballot Position Update] New position, Yes, has been recorded for Eric Rescorla |
2017-04-24
|
09 | Eric Rescorla | Created "Approve" ballot |
2017-04-24
|
09 | Eric Rescorla | Ballot writeup was changed |
2017-04-21
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Mahesh Jethanandani. |
2017-04-21
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani |
2017-04-21
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani |
2017-04-19
|
09 | Francis Dupont | Request for Telechat review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2017-04-19
|
09 | Jean Mahoney | |
2017-04-19
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2017-04-18
|
09 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-04-12
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2017-04-12
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jon Mitchell |
2017-04-11
|
09 | Mahesh Jethanandani | Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Mahesh Jethanandani. Sent review to list. |
2017-04-11
|
09 | Wesley Eddy | Request for Last Call review by TSVART Completed: On the Right Track. Reviewer: Wesley Eddy. Sent review to list. |
2017-04-04
|
09 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2017-04-04
|
09 | Sabrina Tanamal | Request for Last Call review by GENART is assigned to Wassim Haddad(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-ipsecme-tcp-encaps-09.txt, which … Request for Last Call review by GENART is assigned to Wassim Haddad(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-ipsecme-tcp-encaps-09.txt, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal IANA Services Specialist PTI |
2017-04-04
|
09 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Wesley Eddy |
2017-04-04
|
09 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Wesley Eddy |
2017-03-29
|
09 | Amy Vezza | Shepherding AD changed to Eric Rescorla |
2017-03-29
|
09 | Tero Kivinen | Added to session: IETF-98: ipsecme Wed-1300 |
2017-03-28
|
09 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2017-03-28
|
09 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: ipsecme-chairs@ietf.org, Tero Kivinen , kivinen@iki.fi, ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: ipsecme-chairs@ietf.org, Tero Kivinen , kivinen@iki.fi, ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, draft-ietf-ipsecme-tcp-encaps@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (TCP Encapsulation of IKE and IPsec Packets) to Proposed Standard The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'TCP Encapsulation of IKE and IPsec Packets' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-04-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for Security Association establishment and ESP packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-03-28
|
09 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2017-03-28
|
09 | Kathleen Moriarty | Telechat date has been changed to 2017-04-27 from 2017-04-13 |
2017-03-28
|
09 | Kathleen Moriarty | Last call was requested |
2017-03-28
|
09 | Kathleen Moriarty | Last call announcement was changed |
2017-03-28
|
09 | Kathleen Moriarty | Last call was requested |
2017-03-28
|
09 | Kathleen Moriarty | Ballot approval text was generated |
2017-03-28
|
09 | Kathleen Moriarty | Ballot writeup was generated |
2017-03-28
|
09 | Kathleen Moriarty | from AD Evaluation |
2017-03-28
|
09 | Kathleen Moriarty | Last call announcement was generated |
2017-03-19
|
09 | Francis Dupont | Request for Telechat review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2017-03-19
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2017-03-19
|
09 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2017-03-16
|
09 | Jean Mahoney | Closed request for Telechat review by GENART with state 'Withdrawn' |
2017-03-15
|
09 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Russ Mundy |
2017-03-15
|
09 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Russ Mundy |
2017-03-14
|
09 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Mahesh Jethanandani |
2017-03-14
|
09 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Mahesh Jethanandani |
2017-03-12
|
09 | Tommy Pauly | New version available: draft-ietf-ipsecme-tcp-encaps-09.txt |
2017-03-12
|
09 | (System) | New version approved |
2017-03-12
|
09 | (System) | Request for posting confirmation emailed to previous authors: Samy Touati , Tommy Pauly , Ravi Mantha |
2017-03-12
|
09 | Tommy Pauly | Uploaded new revision |
2017-03-09
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2017-03-09
|
08 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2017-03-09
|
08 | Kathleen Moriarty | IESG state changed to AD Evaluation from Publication Requested |
2017-03-09
|
08 | Kathleen Moriarty | Placed on agenda for telechat - 2017-04-13 |
2017-03-01
|
08 | Tero Kivinen | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The type of RFC being requested is Standard track document. This document defines a framing protocol and network peer behavior that allows implementations to run the existing IKEv2 and ESP protocols over TCP. This is the type of RFC indicated on the draft. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for Security Association establishment and ESP packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. Working Group Summary The draft came to the working group out of a need to standardize a push towards adding TCP support for IKE that was coming from several sources (VPN vendors and cellular carriers using IKE for telephony services). Some of the major changes that the WG made early on compared to existing proposals from external bodies was to remove the reliance on encapsulating IKE traffic within TLS. Much of the other WG discussion later on in review revolved around how to best manage the connection establishment and teardown transitions. Document Quality There are several early implementations of the protocol that were made to test interoperability (notably, Cisco and Apple). The draft also received input from vendors that have previously deployed proprietary versions of IPsec over TCP. Personnel The Document Shepherd is Tero Kivinen. The responsible AD is Kathleen Moriarty. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed document few times, and provided some feedback, which has been taken in to the account for latest versions. The document seems to be ready to be published. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? There has been several reviews from the active IPsecME WG members of this draft, and I think we have had enough reviews in the WG. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No broader review is needed. There is the normal issue with TCP inside TCP (or TCP inside the ESP, which is then inside the TCP) but the performance considerations sections already point this out. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns came up in the WG with the current version of the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The active members of the WG have all participated in the discussion about this draft, and given their feedback. We've discussed the draft over the course of several IETF meetings, and there is agreement on the document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None found. Idnits compains about several in-document references being missing as it does not understand that [section 12] refers to this document, not external document. Similarly idnits complains about the [CERTREQ], [CP] etc, i.e., the optional parts of the exchanges, as it confuses them as references. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not Applicable. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Not applicable. The document does not include any IANA requests. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Not applicable. The document does not include any IANA requests. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. No applicable. |
2017-03-01
|
08 | Tero Kivinen | Responsible AD changed to Kathleen Moriarty |
2017-03-01
|
08 | Tero Kivinen | |
2017-03-01
|
08 | Tero Kivinen | IESG state changed to Publication Requested |
2017-03-01
|
08 | Tero Kivinen | IESG process started in state Publication Requested |
2017-02-27
|
08 | Samy Touati | New version available: draft-ietf-ipsecme-tcp-encaps-08.txt |
2017-02-27
|
08 | (System) | New version approved |
2017-02-27
|
08 | (System) | Request for posting confirmation emailed to previous authors: Samy Touati , Tommy Pauly , Ravi Mantha |
2017-02-27
|
08 | Samy Touati | Uploaded new revision |
2017-02-24
|
07 | Tero Kivinen | Changed document writeup |
2017-02-09
|
07 | Tommy Pauly | New version available: draft-ietf-ipsecme-tcp-encaps-07.txt |
2017-02-09
|
07 | (System) | New version approved |
2017-02-09
|
07 | (System) | Request for posting confirmation emailed to previous authors: "Tommy Pauly" , "Samy Touati" , "Ravi Mantha" |
2017-02-09
|
07 | Tommy Pauly | Uploaded new revision |
2017-02-08
|
06 | Tero Kivinen | WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-02-03
|
06 | Tommy Pauly | New version available: draft-ietf-ipsecme-tcp-encaps-06.txt |
2017-02-03
|
06 | (System) | New version approved |
2017-02-03
|
06 | (System) | Request for posting confirmation emailed to previous authors: "Tommy Pauly" , "Samy Touati" , "Ravi Mantha" |
2017-02-03
|
06 | Tommy Pauly | Uploaded new revision |
2017-01-23
|
05 | Tommy Pauly | New version available: draft-ietf-ipsecme-tcp-encaps-05.txt |
2017-01-23
|
05 | (System) | New version approved |
2017-01-23
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Tommy Pauly" , "Samy Touati" , "Ravi Mantha" |
2017-01-23
|
05 | Tommy Pauly | Uploaded new revision |
2017-01-11
|
04 | Tero Kivinen | IETF WG state changed to In WG Last Call from WG Document |
2017-01-11
|
04 | Tero Kivinen | Changed consensus to Yes from Unknown |
2017-01-11
|
04 | Tero Kivinen | |
2016-12-04
|
04 | Tommy Pauly | New version available: draft-ietf-ipsecme-tcp-encaps-04.txt |
2016-12-04
|
04 | (System) | New version approved |
2016-12-04
|
04 | (System) | Request for posting confirmation emailed to previous authors: "Tommy Pauly" , "Samy Touati" , "Ravi Mantha" |
2016-12-04
|
04 | Tommy Pauly | Uploaded new revision |
2016-10-31
|
03 | Tommy Pauly | New version available: draft-ietf-ipsecme-tcp-encaps-03.txt |
2016-10-31
|
03 | (System) | New version approved |
2016-10-31
|
02 | (System) | Request for posting confirmation emailed to previous authors: "Tommy Pauly" , "Samy Touati" , "Ravi Mantha" |
2016-10-31
|
02 | Tommy Pauly | Uploaded new revision |
2016-10-06
|
02 | David Waltermire | Notification list changed to "Tero Kivinen" <kivinen@iki.fi> |
2016-10-06
|
02 | David Waltermire | Document shepherd changed to Tero Kivinen |
2016-08-17
|
02 | Tommy Pauly | New version available: draft-ietf-ipsecme-tcp-encaps-02.txt |
2016-07-07
|
01 | Tommy Pauly | New version available: draft-ietf-ipsecme-tcp-encaps-01.txt |
2016-06-27
|
00 | David Waltermire | This document now replaces draft-pauly-ipsecme-tcp-encaps instead of None |
2016-06-27
|
00 | Tommy Pauly | New version available: draft-ietf-ipsecme-tcp-encaps-00.txt |