Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation
draft-ietf-ipsecme-ikev2-fragmentation-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-11-03
|
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-10-09
|
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-10-06
|
10 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2014-10-03
|
10 | (System) | RFC Editor state changed to AUTH from EDIT |
2014-09-10
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2014-09-10
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2014-09-09
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-09-09
|
10 | (System) | IANA Action state changed to In Progress from On Hold |
2014-09-08
|
10 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-09-04
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent from RFC Ed Queue |
2014-09-04
|
10 | Cindy Morgan | IESG has approved the document |
2014-09-04
|
10 | Cindy Morgan | Ballot approval text was changed |
2014-09-04
|
10 | Cindy Morgan | Ballot approval text was generated |
2014-09-04
|
10 | Cindy Morgan | Ballot writeup was changed |
2014-09-03
|
10 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-09-03
|
10 | (System) | RFC Editor state changed to EDIT |
2014-09-03
|
10 | (System) | Announcement was received by RFC Editor |
2014-09-02
|
10 | (System) | IANA Action state changed to On Hold |
2014-09-02
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent from IESG Evaluation |
2014-09-02
|
10 | Cindy Morgan | IESG has approved the document |
2014-09-02
|
10 | Cindy Morgan | Closed "Approve" ballot |
2014-09-02
|
10 | Cindy Morgan | Ballot approval text was generated |
2014-09-02
|
10 | Cindy Morgan | Ballot writeup was changed |
2014-09-01
|
10 | Benoît Claise | [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss |
2014-07-19
|
10 | Martin Stiemerling | [Ballot comment] The document has improved and addresses my points. |
2014-07-19
|
10 | Martin Stiemerling | [Ballot Position Update] Position for Martin Stiemerling has been changed to No Objection from Discuss |
2014-07-14
|
10 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss |
2014-07-14
|
10 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss |
2014-06-27
|
10 | Kathleen Moriarty | IESG state changed to IESG Evaluation from AD is watching |
2014-06-27
|
10 | Kathleen Moriarty | Ballot writeup was changed |
2014-06-09
|
10 | Valery Smyslov | New version available: draft-ietf-ipsecme-ikev2-fragmentation-10.txt |
2014-06-06
|
09 | Stephen Farrell | [Ballot comment] Since there is a long history of flakey certificate processing in the real world I'd suggest that a new security consideration along these … [Ballot comment] Since there is a long history of flakey certificate processing in the real world I'd suggest that a new security consideration along these lines be added: "It can be dangerous to process fragments before the full set have been received. For example, even if a full certificate has been received in some fragment(s), receivers cannot safely validate that certificate until all fragments are received as that could create a vulnerability if a later (set of) fragment(s) effectively overwrite the bytes of the message containing the certificate. The potential attack would be to send a good certificate in the first set of fragments, but to then replace that with a certificate that has e.g. incorrect naming, in the hope that the first certificate will pass validation, but that later (or higher layer) authorization checks use the most recently received certificate without re-doing validation." --- OLD COMMENTS BELOW - I think it might be useful to add to the security considerations that receivers should not start processing the content of fragments until the entire reassembly process is done. Maybe that's there already somewhere but it wasn't clear to me. The concern is that e.g. a receiver might extract one certificate from a set of fragments and do a lot of work verifying that (e.g. OCSP) before the potential DoS vector is closed off. This is similar to the discuss point above but slightly differnt. - 2.6 says: "if reassembling has already started, check that Total Fragments field is equal to or greater than Total Fragments field in fragments, that have already received" What does that mean exactly? - I agree that an editorial pass is badly needed, and checking that wouuld need some IKE clue, so it might not be enough for the RFC editor and author alone to do that. - Doesn't this update 5996? 2.6.1 says explicitly that it does, but there's nothing in the meta-data about that. I guess a 5996 implementation will still work fine against one that does this because it needs to be negotiated, but did the WG consider that? |
2014-06-06
|
09 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2014-06-06
|
09 | Valery Smyslov | New version available: draft-ietf-ipsecme-ikev2-fragmentation-09.txt |
2014-05-23
|
08 | Valery Smyslov | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2014-05-23
|
08 | Valery Smyslov | New version available: draft-ietf-ipsecme-ikev2-fragmentation-08.txt |
2014-05-08
|
07 | Suresh Krishnan | Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Suresh Krishnan. |
2014-05-03
|
07 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2014-04-24
|
07 | Cindy Morgan | IESG state changed to AD is watching from IESG Evaluation |
2014-04-24
|
07 | Joel Jaeggli | [Ballot comment] coauthor of https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02 it's pretty clear to me that cgnat devices are not the sole offender. any stateful device that uses some kind … [Ballot comment] coauthor of https://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02 it's pretty clear to me that cgnat devices are not the sole offender. any stateful device that uses some kind of an ecmp nexthop or which would need to do reassembly in order to apply policy can get involved. second allowing for fragment sizes substantially below the internet minimums is something a dos risk, e.g. somebody can dole out data a byte at a time for example which can tie up reassembly resources to no end. very small initial fragments a a great reason to discard something imho. |
2014-04-24
|
07 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-04-24
|
07 | Stephen Farrell | [Ballot discuss] I just want to check one thing, which is probably ok, but not clear to me. (Apologies - I didn't have much time … [Ballot discuss] I just want to check one thing, which is probably ok, but not clear to me. (Apologies - I didn't have much time to read this;-) The concern I have is that a sender ought not be able to e.g. overwrite the value sent in a fragment with a later different fragment (say sending a good cert first and then a bogus one later and hoping that the good one is verified before reassembly is complete but the names from the bogus one are used for access control). I think this is probably ok, but just wanted to check. |
2014-04-24
|
07 | Stephen Farrell | [Ballot comment] - I think it might be useful to add to the security considerations that receivers should not start processing the content of fragments … [Ballot comment] - I think it might be useful to add to the security considerations that receivers should not start processing the content of fragments until the entire reassembly process is done. Maybe that's there already somewhere but it wasn't clear to me. The concern is that e.g. a receiver might extract one certificate from a set of fragments and do a lot of work verifying that (e.g. OCSP) before the potential DoS vector is closed off. This is similar to the discuss point above but slightly differnt. - 2.6 says: "if reassembling has already started, check that Total Fragments field is equal to or greater than Total Fragments field in fragments, that have already received" What does that mean exactly? - I agree that an editorial pass is badly needed, and checking that wouuld need some IKE clue, so it might not be enough for the RFC editor and author alone to do that. - Doesn't this update 5996? 2.6.1 says explicitly that it does, but there's nothing in the meta-data about that. I guess a 5996 implementation will still work fine against one that does this because it needs to be negotiated, but did the WG consider that? |
2014-04-24
|
07 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2014-04-24
|
07 | Martin Stiemerling | [Ballot discuss] I have a concern about this draft being published as it is right now and this concern is about not re-using RFC 4821 … [Ballot discuss] I have a concern about this draft being published as it is right now and this concern is about not re-using RFC 4821 in an appropriate way. Let's go step by step: 1) In Section 2.4, the first bullet list: It is easy to write text that an initiator can decide on some other knowledge whether it should or shouldn't fragment right away from the beginning. However, when saying this, you will need more text that discusses the operational side of this. For instance, it is not sufficient to blindly trust old data about the path's MTU between the initiator and the responder, as the characteristics of the path might have changed or the believe to use the same path as before is just wrong. 2) In Section 2.4, the second bullet list on page 6, bullet 1 and bullet 2: This bullet assumes that the the way back from the responder to the initiator shares the same properties as the way forward from the initiator to the responder. I am not an IKE expert, but if the response is big, actually bigger than the PMTU on the way back, and the request was not fragmented, what happens in this case? Bullet 2 is pointing ot this, but the current text is not very precis other than saying "has some knowledge". Further, bullet 2 contradicts bullet 1's SHOULD. 3) Section 2.5.2: This section is hitting my main concern about not re-using RFC 4821's mechnism. For instance: - You start from a large value and if this doesn't work you move to a smaller value. What is the recommended value for this and what steps do you take in decreasing the packet size? This sounds implementation specific, but implementers will value guidance on what to do. - You talk about a timer that should be reasonable. What is reasonable? - The text here worries me: "After reaching the smallest allowed value for fragmentation threshold implementation MUST continue probing using it until either exchange completes or times out." So, you are continuesly probing the network though have rached your threshold and you still do not have success? 4) Section 2.6, page 11: "If receiver doesn't get all IKE Fragment Messages needed to reassemble original Message for some Exchange within a timeout interval,". This draft isn't specifying any timeout value. See also my comment about interworking with any IKE timers. 5) Section 5, this text: "To mitigate the impact of this attack, it is RECOMMENDED that receiver limits the number of fragments it stores in reassembling queue so that the sum of the sizes of Encrypted Fragment Payload contents (after decryption) for fragments that are already placed into reassembling queue be less than some value that is reasonable for the implementation. " While buffer sizes are implementation specific, I do see this text as pure handwaiving, as it doesn't have any good guidance for implementers. I would add this as a comment, but if the number of fragments it stores in reassembling queue is too small there is an interoperability issue, as the sender of the fragments cannot know what the acceptable lower limit is. Therefore this goes as an DISCUSS issue. 6)I can continue this list of open issues and questions, but instead let's ask the questions about why not re-using RFC 4821: In RFC 4821 there is text about what is required by the particular protocol in order to enable PLPMTUD, in Section 6.1. "Mechanism to Detect Loss" it says: "It is important that the Packetization Layer has a timely and robust mechanism for detecting and reporting losses." Ok, I can see that UDP itself does not have this type of information built-in, but the rest of the document makes reasonable assumptions on how you can use PLPMTUD even without using TCP or SCTP. For example, Section 10.4. "Probing Method Using Applications" even discusses doing PLPMTUD out of an application, which IKE is. Please note that similar concerns where raised in Oct 2013 during the TSV-DIR review by Joe Touch and Matt Mathis. Thread starts here: http://www.ietf.org/mail-archive/web/ipsec/current/msg08653.html. |
2014-04-24
|
07 | Martin Stiemerling | Ballot discuss text updated for Martin Stiemerling |
2014-04-24
|
07 | Martin Stiemerling | [Ballot discuss] I have a concern about this draft being published as it is right now and this concern is about not re-using RFC 4821 … [Ballot discuss] I have a concern about this draft being published as it is right now and this concern is about not re-using RFC 4821 in an appropriate way. Let's go step by step: 1) In Section 2.4, the first bullet list: It is easy to write text that an initiator can decide on some other knowledge whether it should or shouldn't fragment right away from the beginning. However, when saying this, you will need more text that discusses the operational side of this. For instance, it is not sufficient to blindly trust old data about the path's MTU between the initiator and the responder, as the characteristics of the path might have changed or the believe to use the same path as before is just wrong. 2) In Section 2.4, the second bullet list on page 6, bullet 1 and bullet 2: This bullet assumes that the the way back from the responder to the initiator shares the same properties as the way forward from the initiator to the responder. I am not an IKE expert, but if the response is big, actually bigger than the PMTU on the way back, and the request was not fragmented, what happens in this case? Bullet 2 is pointing ot this, but the current text is not very precis other than saying "has some knowledge". Further, bullet 2 contradicts bullet 1's SHOULD. 3) Section 2.5.2: This section is hitting my main concern about not re-using RFC 4821's mechnism. For instance: - You start from a large value and if this doesn't work you move to a smaller value. What is the recommended value for this and what steps do you take in decreasing the packet size? This sounds implementation specific, but implementers will value guidance on what to do. - You talk about a timer that should be reasonable. What is reasonable? - The text here worries me: "After reaching the smallest allowed value for fragmentation threshold implementation MUST continue probing using it until either exchange completes or times out." So, you are continuesly probing the network though have rached your threshold and you still do not have success? 4) Section 2.6, page 11: "If receiver doesn't get all IKE Fragment Messages needed to reassemble original Message for some Exchange within a timeout interval,". This draft isn't specifying any timeout value. See also my comment about interworking with any IKE timers. 5) Section 5, this text: "To mitigate the impact of this attack, it is RECOMMENDED that receiver limits the number of fragments it stores in reassembling queue so that the sum of the sizes of Encrypted Fragment Payload contents (after decryption) for fragments that are already placed into reassembling queue be less than some value that is reasonable for the implementation. " While buffer sizes are implementation specific, I do see this text as pure handwaiving, as it doesn't have any good guidance for implementers. I would add this as a comment, but if the number of fragments it stores in reassembling queue is too small there is an interoperability issue, as the sender of the fragments cannot know what the acceptable lower limit is. Therefore this goes as an DISCUSS issue. 6)I can continue this list of open issues and questions, but instead let's ask the questions about why not re-using RFC 4821: In RFC 4821 there is text about what is required by the particular protocol in order to enable PLPMTUD, in Section 6.1. "Mechanism to Detect Loss" it says: "It is important that the Packetization Layer has a timely and robust mechanism for detecting and reporting losses." Ok, I can see that UDP itself does not have this type of information built-in, but the rest of the document makes reasonable assumptions on how you can use PLPMTUD even without using TCP or SCTP. For example, Section 10.4. "Probing Method Using Applications" even discusses doing PLPMTUD out of an application, which IKE is. Please note that similar concerns where raised in Oct 2013 during the TSV-DIR review by Joe Touch and Matt Mathis. Thread starts here: http://www.ietf.org/mail-archive/web/ipsec/current/msg08653.html. |
2014-04-24
|
07 | Martin Stiemerling | Ballot discuss text updated for Martin Stiemerling |
2014-04-24
|
07 | Martin Stiemerling | [Ballot discuss] I have a concern about this draft being published as it is right now and this concern is about not re-using RFC 4821 … [Ballot discuss] I have a concern about this draft being published as it is right now and this concern is about not re-using RFC 4821 in an appropriate way. Let's go step by step: 1) In Section 2.4, the first bullet list: It is easy to write text that an initiator can decide on some other knowledge whether it should or shouldn't fragment right away from the beginning. However, when saying this, you will need more text that discusses the operational side of this. For instance, it is not sufficient to blindly trust old data about the path's MTU between the initiator and the responder, as the characteristics of the path might have changed or the believe to use the same path as before is just wrong. 2) In Section 2.4, the second bullet list on page 6, bullet 1 and bullet 2: This bullet assumes that the the way back from the responder to the initiator shares the same properties as the way forward from the initiator to the responder. I am not an IKE expert, but if the response is big, actually bigger than the PMTU on the way back, and the request was not fragmented, what happens in this case? Bullet 2 is pointing ot this, but the current text is not very precis other than saying "has some knowledge". Further, bullet 2 contradicts bullet 1's SHOULD. 3) Section 2.5.2: This section is hitting my main concern about not re-using RFC 4821's mechnism. For instance: - You start from a large value and if this doesn't work you move to a smaller value. What is the recommended value for this and what steps do you take in decreasing the packet size? This sounds implementation specific, but implementers will value guidance on what to do. - You talk about a timer that should be reasonable. What is reasonable? - The text here worries me: "After reaching the smallest allowed value for fragmentation threshold implementation MUST continue probing using it until either exchange completes or times out." So, you are continuesly probing the network though have rached your threshold and you still do not have success? 4) Section 2.6, page 11: "If receiver doesn't get all IKE Fragment Messages needed to reassemble original Message for some Exchange within a timeout interval,". This draft isn't specifying any timeout value. See also my comment about interworking with any IKE timers. 5)I can continue this list of open issues and questions, but instead let's ask the questions about why not re-using RFC 4821: In RFC 4821 there is text about what is required by the particular protocol in order to enable PLPMTUD, in Section 6.1. "Mechanism to Detect Loss" it says: "It is important that the Packetization Layer has a timely and robust mechanism for detecting and reporting losses." Ok, I can see that UDP itself does not have this type of information built-in, but the rest of the document makes reasonable assumptions on how you can use PLPMTUD even without using TCP or SCTP. For example, Section 10.4. "Probing Method Using Applications" even discusses doing PLPMTUD out of an application, which IKE is. Please note that similar concerns where raised in Oct 2013 during the TSV-DIR review by Joe Touch and Matt Mathis. Thread starts here: http://www.ietf.org/mail-archive/web/ipsec/current/msg08653.html. |
2014-04-24
|
07 | Martin Stiemerling | [Ballot comment] I share the comments about readability of this document and the not correct usage of RFC 2119 key words in a number of … [Ballot comment] I share the comments about readability of this document and the not correct usage of RFC 2119 key words in a number of places. - Section 2.6, page 11 mentions the IKE timers out of RFC 5996, Section 2.1. I wonder if there is any bad interactions between those IKE level times and the fragmentation timers that has not yet been explored. - Further, there is an update in the pipe of RFC 5996: https://ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/. Is there anything in the update that should be considered for this draft? |
2014-04-24
|
07 | Martin Stiemerling | Ballot comment and discuss text updated for Martin Stiemerling |
2014-04-24
|
07 | Martin Stiemerling | [Ballot discuss] I have a concern about this draft being published as it is right now and this concern is about not re-using RFC 4821 … [Ballot discuss] I have a concern about this draft being published as it is right now and this concern is about not re-using RFC 4821 in an appropriate way. Let's go step by step: 1) In Section 2.4, the first bullet list: It is easy to write text that an initiator can decide on some other knowledge whether it should or shouldn't fragment right away from the beginning. However, when saying this, you will need more text that discusses the operational side of this. For instance, it is not sufficient to blindly trust old data about the path's MTU between the initiator and the responder, as the characteristics of the path might have changed or the believe to use the same path as before is just wrong. 2) In Section 2.4, the second bullet list on page 6, bullet 1 and bullet 2: This bullet assumes that the the way back from the responder to the initiator shares the same properties as the way forward from the initiator to the responder. I am not an IKE expert, but if the response is big, actually bigger than the PMTU on the way back, and the request was not fragmented, what happens in this case? Bullet 2 is pointing ot this, but the current text is not very precis other than saying "has some knowledge". Further, bullet 2 contradicts bullet 1's SHOULD. 3) Section 2.5.2: This section is hitting my main concern about not re-using RFC 4821's mechnism. For instance: - You start from a large value and if this doesn't work you move to a smaller value. What is the recommended value for this and what steps do you take in decreasing the packet size? This sounds implementation specific, but implementers will value guidance on what to do. - You talk about a timer that should be reasonable. What is reasonable? - The text here worries me: "After reaching the smallest allowed value for fragmentation threshold implementation MUST continue probing using it until either exchange completes or times out." So, you are continuesly probing the network though have rached your threshold and you still do not have success? I can continue this list of open issues and questions, but instead let's ask the questions about why not re-using RFC 4821: In RFC 4821 there is text about what is required by the particular protocol in order to enable PLPMTUD, in Section 6.1. "Mechanism to Detect Loss" it says: "It is important that the Packetization Layer has a timely and robust mechanism for detecting and reporting losses." Ok, I can see that UDP itself does not have this type of information built-in, but the rest of the document makes reasonable assumptions on how you can use PLPMTUD even without using TCP or SCTP. For example, Section 10.4. "Probing Method Using Applications" even discusses doing PLPMTUD out of an application, which IKE is. Please note that similar concerns where raised in Oct 2013 during the TSV-DIR review by Joe Touch and Matt Mathis. Thread starts here: http://www.ietf.org/mail-archive/web/ipsec/current/msg08653.html. |
2014-04-24
|
07 | Martin Stiemerling | [Ballot comment] I share the comments about readability of this document and the not correct usage of RFC 2119 key words in a number of … [Ballot comment] I share the comments about readability of this document and the not correct usage of RFC 2119 key words in a number of places. |
2014-04-24
|
07 | Martin Stiemerling | Ballot comment and discuss text updated for Martin Stiemerling |
2014-04-23
|
07 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2014-04-23
|
07 | Pete Resnick | [Ballot discuss] 2.4: I actually think that the problems in this section are more serious than Barry's COMMENT would indicate. Even leaving aside the grammatical … [Ballot discuss] 2.4: I actually think that the problems in this section are more serious than Barry's COMMENT would indicate. Even leaving aside the grammatical issues, which makes some of this section confusing, as written I think this section is actually self-contradictory: The opening paragraph indicates that the initiator is free to fragment (or not) completely at its discretion, but then the bullets indicate that there are interoperability requirements with fragmenting that do not agree with that. My guess is that all of the SHOULDs and SHOULD NOTs in 2.4 are actually just suggestions, but honestly I can't be sure: None of them explain why it's problematic to deviate from them, so I can't tell if they're actually indicating interoperability or security problems or are simply implementation advice. Finally, I find this "knowledge or suspicions" text to be very odd in the context of requirements. I'm supposed to base my implementation on whether I have suspicions that something might happen? I could spend time giving you suggested text, but I figure that wouldn't be fruitful as you'd have to correct all of my technical errors. Please give this section another go. 2.5: Message to be fragmented MUST contain Encrypted Payload. Ungrammatical sentences with protocol requirements always give me pause, but I actually don't understand what the above requirement is trying to say. Is it that the fragment MUST be encrypted? I don't understand. When prepending IKE Header, Length field MUST be adjusted to reflect the length of constructed message and Next Payload field MUST reflect payload type of the first Payload in the constructed message (that in most cases will be Encrypted Fragment Payload). That isn't clear to me. Do you mean that the IKE Header Length field MUST be the length of the header plus the length of the fragment, or do you mean that it is the original length of the entire unfragmented payload? What does "the constructed message" refer to? |
2014-04-23
|
07 | Pete Resnick | [Ballot comment] 2.3: Some unnecessary bits: s/MAY indicate/indicates s/MUST be/Set to (The MUSTs don't add anything, since I presume there's nothing that an implementation could … [Ballot comment] 2.3: Some unnecessary bits: s/MAY indicate/indicates s/MUST be/Set to (The MUSTs don't add anything, since I presume there's nothing that an implementation could conceivably put in there by mistake. If you're trying to prevent specific behavior, that's different.) 2.5.1: "If sender has some knowledge about PMTU size it MAY use it." Why is that a MAY? Isn't it that you SHOULD use PMTU if you already have it, and use the other methods if you don't? |
2014-04-23
|
07 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick |
2014-04-23
|
07 | Barry Leiba | [Ballot comment] I have no objection to the publication, but I do have a substantive, non-blocking comment that I'd like you to please consider: -- … [Ballot comment] I have no objection to the publication, but I do have a substantive, non-blocking comment that I'd like you to please consider: -- Section 2.4 -- The pair of bullet lists strikes me as something of a 2119 mess. I'm not sure that the qualified "MAY"s are really intended to be qualified by the "if" conditions, or whether those conditions are only meant to be explanatory. I don't understand why there's a protocol-related difference between the first bullet (MAY) and the second (SHOULD). I think the second sentence of the fourth bullet is unnecessary, as a special case of the first sentence. I think the "MAY" in the last bullet is somewhat silly -- it's always an option to use unfragmented messages. So, correct me if I'm wrong, but there is no *protocol requirement* either way here. Whether one side is fragmenting or not is detectable by the other side, and both sides can handle either type. You're not, therefore, providing any protocol needs here. What you're doing is giving advice on when to use IKE fragmentation to avoid IP-layer fragmentation... and when *not* to use IKE fragmentation because it's not necessary and you want to avoid the overhead. Is that right? You're probably not going to want to do this (and this is *not* a blocking comment, so I'm not going to fight about it), but I'd like to see these bullet lists re-worked with that in mind, and with the correct meanings of "SHOULD", "SHOULD NOT", and especially "MAY" (entirely optional, one way or the other, with no recommendation either way) in mind, and with explanations of *why* you SHOULD or SHOULD NOT do it. For what it's worth, if you *are* willing to consider that, I'll be happy to propose specific text as a starting point. |
2014-04-23
|
07 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-04-23
|
07 | Spencer Dawkins | [Ballot comment] Thank you for discussing my Discuss with me. I completely missed the description of the double use for Total Fragments in this draft … [Ballot comment] Thank you for discussing my Discuss with me. I completely missed the description of the double use for Total Fragments in this draft (not only signaling the number of fragments that the sender is sending, but also signaling that the sender has lowered the fragmentation threshold, so the receiver should discard previously received fragments and restart reassembly). You're right - the text describes this, but when I went back through the document looking for the description, I still missed it on my second attempt. The description is split between a couple of sections, and appears as part of the step-by-step procedure. Perhaps this critical point would be easier to spot if you included a high-level description separately before the low-level text. But I'm clearing my Discuss. |
2014-04-23
|
07 | Spencer Dawkins | Ballot comment text updated for Spencer Dawkins |
2014-04-23
|
07 | Spencer Dawkins | [Ballot comment] Thank you for discussing my Discuss with me. I completely missed the double use for Total Fragments in this draft (not only signaling … [Ballot comment] Thank you for discussing my Discuss with me. I completely missed the double use for Total Fragments in this draft (not only signaling the number of fragments that the sender is sending, but also signaling that the sender has lowered the fragmentation threshold, so the receiver should discard previously received fragments and restart reassembly). You're right - the text describes this, but when I went back through the document looking for the description, I still missed it on my second attempt. The description is split between a couple of sections, and appears as part of the step-by-step procedure. Perhaps this critical point would be easier to spot if you included a high-level description separately before the low-level text. But I'm clearing my Discuss. |
2014-04-23
|
07 | Spencer Dawkins | [Ballot Position Update] Position for Spencer Dawkins has been changed to No Objection from Discuss |
2014-04-23
|
07 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2014-04-23
|
07 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2014-04-23
|
07 | Martin Stiemerling | [Ballot discuss] I am already raising my DISCUSS just to let the responsible AD and the authors know in advance. I am late with reading … [Ballot discuss] I am already raising my DISCUSS just to let the responsible AD and the authors know in advance. I am late with reading and will still need until Thursday to get my full review entered. My biggest issue with the draft (amongst a number of others) is: This draft must not invent any new path MTU discovery, as we have already two RFCs describing PMTU. Those two are mentioned in this draft, but I have not seen any reasons why another mechanism is needed. Further, there are some values to be defined before any PMTU can be done successfully. For instance, this draft says in Section 2.5.2 "resaonable time after several retransmissions". What is such a resonable time? |
2014-04-23
|
07 | Martin Stiemerling | [Ballot Position Update] New position, Discuss, has been recorded for Martin Stiemerling |
2014-04-22
|
07 | Brian Haberman | [Ballot discuss] I have no problems with the publication of this document, but there are some points I would like to see discussed. 1. Like … [Ballot discuss] I have no problems with the publication of this document, but there are some points I would like to see discussed. 1. Like Benoit's DISCUSS, I know there is useful information available on fragmentation issues in other documents. Ron Bonica put together useful information in the expired draft-bonica-6man-frag-deprecate that describes why fragmentation at the IP layer is troublesome. Since it is expired, I would suggest working with those authors to include some of their clearer justification text in this document. 2. I am troubled by the choice of 2119 keywords in some places. For example, section 2.3 says: "Initiator MAY indicate its support for IKE Fragmentation and willingness to use it by ..." Why is this a MAY? It is not needed for interoperability. The inclusion of the indicator is driven by support for this spec and any user configuration implemented for it. 3. The rules in Section 2.4 are rather loose. Why is there so much leeway in the rules for sending and receiving? How does an implementer code suspicions? Can the first two guidelines for initiators be combined? The first rule for responders assumes that network paths are symmetric. Is there justification for that assumption? 4. The third bullet in Section 2.5.2 seems to contradict the need to do any PMTUD. Couldn't you just fragment IKE_AUTH messages to the 1280/576 sizes and be done with it? |
2014-04-22
|
07 | Brian Haberman | [Ballot comment] 1. I found some of the text hard to parse on first read. I would suggest having someone with an IKE background do … [Ballot comment] 1. I found some of the text hard to parse on first read. I would suggest having someone with an IKE background do an editorial pass. Section 2.2 is an example of text that could be cleaned up. |
2014-04-22
|
07 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2014-04-22
|
07 | Benoît Claise | [Ballot discuss] Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use value 1280 bytes as a maximum IP Datagram … [Ballot discuss] Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use value 1280 bytes as a maximum IP Datagram size ([RFC2460]) ... Initiator MAY try to discover path MTU by probing several values of fragmentation threshold. ... In most cases PMTU discovery will not be needed, as using values, recommended in section Section 2.5.1, should suffice. It is expected, that PMTU discovery may be useful in environments where PMTU size are smaller, than those listed in Section 2.5.1, for example due to the presence of intermediate tunnels. There is no MUST for PMTUD (like in RFC 2460 btw). However, you have tunnels, you believe that you have avoided IP fragmentation (and the attack) by implementing this spec, but actually you have no protection. Don't you want to impose PMTUD with a single packet size = 1280 octets (the recommended value in RFC 2460), as condition to understand if a full PMTUD is required? What is discussed in the WG? |
2014-04-22
|
07 | Benoît Claise | [Ballot comment] - It was found by people deploying IKE, that some ISPs have begun to drop IP fragments, violating that requirement. http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02 provides … [Ballot comment] - It was found by people deploying IKE, that some ISPs have begun to drop IP fragments, violating that requirement. http://tools.ietf.org/html/draft-taylor-v6ops-fragdrop-02 provides pretty background info. Too bad it's not an RFC yet. Anyway, it can still be used as a reference. - Maybe introduce earlier, somewhere in the introduction, that this problem is valid for both IPv4 and IPv6. |
2014-04-22
|
07 | Benoît Claise | [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise |
2014-04-21
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2014-04-20
|
07 | Spencer Dawkins | [Ballot discuss] This is a well-written document - thanks for that. I have one concern (spread over two sections, but I think I'm poking the … [Ballot discuss] This is a well-written document - thanks for that. I have one concern (spread over two sections, but I think I'm poking the same bear in both sections) that I'd like to understand better before balloting No-Obj. In this text, in Section 2.6. Receiving IKE Fragment Message: * if reassembling has already started, check that Total Fragments field is equal to or greater than Total Fragments field in fragments, that have already received I'm really struggling to parse this bullet - I'm guessing * if reassembling has already started, check that Total Fragments field is equal to or greater than Total Fragments field in fragments that have already been received ^^^^ is close to what is meant (extra comma PLUS missing word), but I'm guessing - please fix it! So, beyond that ... I WAS reading this to say that I can fragment a payload into four fragments, send the first three with Total Fragments set to 3, and then send the fourth fragment with Total Fragments set to 4, and that works. But then the other shoe drops a couple of bullets later, in this text: o If reassembling isn't finished yet and Total Fragments field in received IKE Fragment Message is greater than this field in previously received fragments, receiver MUST discard all received fragments and start reassembling over with just received IKE Fragment Message. If so, is it correct to say "a sender can't shrink Total Fragments below what's already been sent within the same Message ID, and can grow Total Fragments beyond what's already been sent with previous fragments with the same Message ID, but the receiver will discard all of the previous fragments and start reassembly with the fragment that arrived with the new, larger Total Fragments", or something like that? Mumble. Is this all required to accommodate intermediate states that could happen during PMTU discovery? That would have all been part of my Comments, until I got down to this text, in 2.6.1. Changes in Replay Protection Logic If Responder receives a replay IKE Fragment Message for already reassembled, verified and processed fragmented message, it MUST retransmit response back to Initiator, but only if Fragment Number field in Encrypted Fragment Payload is equal to 1 and MUST silently discard received message otherwise. If Total Fragments field in received IKE Fragment Message is greater than in IKE Fragment Messages that already processed fragmented message was reassembled from, Responder MAY refragment its response message using smaller fragmentation threshold before resending it back to Initiator. In this case Total Fragments field in new IKE Fragment Messages MUST be ^^^^^^^ greater than in previously sent IKE Fragment Messages. ^^^^^^^^^^^^ If Initiator doesn't receive any of response IKE Fragment Messages within a timeout interval, it MAY refragment request Message using smaller fragmentation threshold before retransmitting it (see Section 2.5.1). In this case Total Fragments field in new IKE Fragment Messages MUST be greater than in previously sent IKE ^^^^^^^^^^^^^^^^^^^^ Fragment Messages. it looks like you're using a changed Total Fragments value to signal the other side to discard everything (except the fragment with the changed Total Fragments field) and start over on reassembling this payload, is that right? If so, perhaps the MUST should say that more clearly - something like In this case the new fragmentation threshold MUST be small enough to increase number of fragments, so that the Total Fragments field in new IKE Fragment Messages will be greater than in previously sent IKE Fragment Messages, and the receiver will discard any previously-received fragments and restart reassembly with this fragment. (I'm thinking of a scenario where payload length is 1000 bytes, the sender is using a fragmentation threshold of 400 bytes and tries to send 400+400+200, and then uses a smaller fragmentation threshold of 350 bytes and successfully sends 350+350+300, also in three fragments, so the receiver doesn't handle that correctly. You want the sender to use an even smaller fragmentation threshold of 333 bytes, sending 333+333+333+1 in four fragments - does that make sense?) |
2014-04-20
|
07 | Spencer Dawkins | Ballot discuss text updated for Spencer Dawkins |
2014-04-20
|
07 | Spencer Dawkins | [Ballot discuss] This is a well-written document - thanks for that. I have one concern (spread over two sections, but I think I'm poking the … [Ballot discuss] This is a well-written document - thanks for that. I have one concern (spread over two sections, but I think I'm poking the same bear in both sections) that I'd like to understand better before balloting No-Obj. In this text, in Section 2.6. Receiving IKE Fragment Message: * if reassembling has already started, check that Total Fragments field is equal to or greater than Total Fragments field in fragments, that have already received I'm really struggling to parse this bullet - I'm guessing * if reassembling has already started, check that Total Fragments field is equal to or greater than Total Fragments field in fragments that have already been received ^^^^ is close to what is meant (extra comma PLUS missing word), but I'm guessing - please fix it! So, beyond that ... I WAS reading this to say that I can fragment a payload into four fragments, send the first three with Total Fragments set to 3, and then send the fourth fragment with Total Fragments set to 4, and that works. But then the other shoe drops a couple of bullets later, in this text: o If reassembling isn't finished yet and Total Fragments field in received IKE Fragment Message is greater than this field in previously received fragments, receiver MUST discard all received fragments and start reassembling over with just received IKE Fragment Message. If so, is it correct to say "a sender can't shrink Total Fragments below what's already been sent within the same Message ID, and can grow Total Fragments beyond what's already been sent with previous fragments with the same Message ID, but the receiver will discard all of the previous fragments and start reassembly with the fragment that arrived with the new, larger Total Fragments", or something like that? Mumble. Is this all required to accommodate intermediate states that could happen during PMTU discovery? That would have all been part of my Comments, until I got down to this text, in 2.6.1. Changes in Replay Protection Logic If Responder receives a replay IKE Fragment Message for already reassembled, verified and processed fragmented message, it MUST retransmit response back to Initiator, but only if Fragment Number field in Encrypted Fragment Payload is equal to 1 and MUST silently discard received message otherwise. If Total Fragments field in received IKE Fragment Message is greater than in IKE Fragment Messages that already processed fragmented message was reassembled from, Responder MAY refragment its response message using smaller fragmentation threshold before resending it back to Initiator. In this case Total Fragments field in new IKE Fragment Messages MUST be ^^^^^^^ greater than in previously sent IKE Fragment Messages. ^^^^^^^^^^^^ If Initiator doesn't receive any of response IKE Fragment Messages within a timeout interval, it MAY refragment request Message using smaller fragmentation threshold before retransmitting it (see Section 2.5.1). In this case Total Fragments field in new IKE Fragment Messages MUST be greater than in previously sent IKE ^^^^^^^^^^^^^^^^^^^^ Fragment Messages. it looks like you're using a changed Total Fragments value to signal the other side to discard everything (except the fragment with the changed Total Fragments field) and start over on reassembling this payload, is that right? If so, perhaps the MUST needs to state that explicitly - something like In this case the new fragmentation threshold MUST be small enough to increase number of fragments, so that the Total Fragments field in new IKE Fragment Messages will be greater than in previously sent IKE Fragment Messages. (I'm thinking of a scenario where payload length is 1000 bytes, the sender is using a fragmentation threshold of 400 bytes and tries to send 400+400+200, and then uses a smaller fragmentation threshold of 350 bytes and successfully sends 350+350+300, also in three fragments, so the receiver doesn't handle that correctly. You want the sender to use an even smaller fragmentation threshold of 333 bytes, sending 333+333+333+1 in four fragments - does that make sense?) |
2014-04-20
|
07 | Spencer Dawkins | [Ballot comment] In this text, in Section 1. Introduction: Widespread deployment of Carrier-Grade NATs (CGN) introduces new challenges. RFC6888 [RFC6888] describes … [Ballot comment] In this text, in Section 1. Introduction: Widespread deployment of Carrier-Grade NATs (CGN) introduces new challenges. RFC6888 [RFC6888] describes requirements for CGNs. It states, that CGNs must comply with Section 11 of RFC4787 [RFC4787], which requires NAT to support receiving IP fragments (REQ-14). In real life fulfillment of this requirement creates an additional burden in terms of memory, especially for high-capacity devices, used in CGNs. It was found by people deploying IKE, that some ISPs have begun to drop IP fragments, violating that requirement. ^^^^^ I'm thinking that "begun" is kind of generous here ... NATs dropping IP fragments is called out in Section 3 of https://tools.ietf.org/html/rfc3424, published in 2002, and I don't think that was a new thing then. Is it possible to make this sound less like it's a recent development? In this text, in 2.2. Limitations As IKE Fragment Messages are cryptographically protected, SK_a and SK_e must already be calculated. In general, it means that original message can be fragmented if and only if it contains Encrypted Payload. This implies that messages of the IKE_SA_INIT Exchange cannot be fragmented. In most cases this is not a problem, since IKE_SA_INIT messages are usually small enough to avoid IP fragmentation. But in some cases (advertising a badly structured long list of algorithms, using large MODP Groups, etc.) these messages may become fairly large and get fragmented by IP level. In this case the described solution won't help. I think I understand what to do from the text, if this is a problem. Among existing IKEv2 extensions, messages of IKE_SESSION_RESUME Exchange, defined in [RFC5723], cannot be fragmented either. See Section 3 for details. Another limitation is that the minimal size of IP Datagram bearing IKE Fragment Message is about 100 bytes depending on the algorithms employed. According to [RFC0791] the minimum IP Datagram size that is guaranteed not to be further fragmented is 68 bytes. So, even the smallest IKE Fragment Messages could be fragmented by IP level in some circumstances. But such extremely small PMTU sizes are very rare in real life. I'm not sure what to do here. I'm guessing that the answer would be "if the path MTU is so small that you can't send IKE Fragment Messages without IP fragmentation also occurs, don't bother doing IKE fragmentation", but I'm wondering if you could make an explicit recommendation about that? In this text, in Section 4. Transport Considerations With IKE Fragmentation if any single IKE Fragment Message get lost, receiver becomes unable to reassemble original Message. So, in general, using IKE Fragmentation implies higher probability for the Message not to be delivered to the peer. Although in most network environments the difference will be insignificant, on some lossy networks it may become noticeable. When using IKE Fragmentation implementations MAY use longer timeouts and do more retransmits before considering peer dead. I don't understand. I was reading the retransmit behavior as IF IKEv2 fragmenting and fragments get lost retransmit the entire payload until you give up ELSE IF IP fragmenting and fragments get lost retransmit the entire packet until you give up ELSE you need to fragment and don't fragment nothing gets through until you give up or am I misunderstanding what you're comparing "higher probability" to? |
2014-04-20
|
07 | Spencer Dawkins | [Ballot Position Update] New position, Discuss, has been recorded for Spencer Dawkins |
2014-04-18
|
07 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2014-04-18
|
07 | Kathleen Moriarty | Removed telechat returning item indication |
2014-04-18
|
07 | Kathleen Moriarty | Telechat date has been changed to 2014-04-24 from 2014-04-03 |
2014-04-18
|
07 | Kathleen Moriarty | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2014-04-18
|
07 | Kathleen Moriarty | IESG state changed to Waiting for AD Go-Ahead from Waiting for Writeup |
2014-04-18
|
07 | Kathleen Moriarty | Ballot has been issued |
2014-04-18
|
07 | Kathleen Moriarty | [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty |
2014-04-18
|
07 | Kathleen Moriarty | Created "Approve" ballot |
2014-04-18
|
07 | Kathleen Moriarty | Ballot writeup was changed |
2014-04-18
|
07 | Paul Hoffman | 1. Summary Paul Hoffman (IPsecME WG co-chair) is the document shepherd and Kathleen Moriarty is the responsible AD. This document describes a method to avoid … 1. Summary Paul Hoffman (IPsecME WG co-chair) is the document shepherd and Kathleen Moriarty is the responsible AD. This document describes a method to avoid IP fragmentation in large IKEv2 messages. It shows how to perform fragmentation in IKEv2 itself, replacing them by series of smaller messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. Given that this is a protocol extension, it is meant to be a Proposed Standard. 2. Review and Consensus The WG discussion of the document was fairly good, with about average participation (which for the IPsecME WG means "the chairs had to beg a bit for more participants, but we then got them"). We also got a "TSVDIR-ish review" of the draft, which got good discussion on the list. There was a reasonable amount of give-and-take, and the WG Last Call was uncontentious. A significant point was brought up during IETF Last Call, and was added to the Security Considerations. 3. Intellectual Property The author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points There are no normative downrefs. The IANA Considerations are short and to the point. The expert review for the two items there has not been done yet, but the designated expert participated in the WG Last Call, so this is not likely to be an issue. |
2014-04-18
|
07 | Paul Hoffman | 1. Summary Paul Hoffman (IPsecME WG co-chair) is the document shepherd and Kathleen Moriarty is the responsible AD. This document describes a method to avoid … 1. Summary Paul Hoffman (IPsecME WG co-chair) is the document shepherd and Kathleen Moriarty is the responsible AD. This document describes a method to avoid IP fragmentation in large IKEv2 messages. It shows how to perform fragmentation in IKEv2 itself, replacing them by series of smaller messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. Given that this is a protocol extension, it is meant to be a Proposed Standard. 2. Review and Consensus The WG discussion of the document was fairly good, with about average participation (which for the IPsecME WG means "the chairs had to beg a bit for more participants, but we then got them"). We also got a "TSVDIR-ish review" of the draft, which got good discussion on the list. There was a reasonable amount of give-and-take, and the WG Last Call was uncontentious. 3. Intellectual Property The author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points There are no normative downrefs. The IANA Considerations are short and to the point. The expert review for the two items there has not been done yet, but the designated expert participated in the WG Last Call, so this is not likely to be an issue. |
2014-04-10
|
07 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Derek Atkins. |
2014-04-07
|
07 | Kathleen Moriarty | Ballot approval text was changed |
2014-04-04
|
07 | Valery Smyslov | New version available: draft-ietf-ipsecme-ikev2-fragmentation-07.txt |
2014-03-15
|
06 | Paul Hoffman | Document shepherd changed to Paul E. Hoffman |
2014-03-15
|
06 | Paul Hoffman | 1. Summary Paul Hoffman (IPsecME WG co-chair) is the document shepherd and Kathleen Moriarty is the responsible AD. This document describes a method to avoid … 1. Summary Paul Hoffman (IPsecME WG co-chair) is the document shepherd and Kathleen Moriarty is the responsible AD. This document describes a method to avoid IP fragmentation in large IKEv2 messages. It shows how to perform fragmentation in IKEv2 itself, replacing them by series of smaller messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. Given that this is a protocol extension, it is meant to be a Proposed Standard. 2. Review and Consensus The WG discussion of the document was fairly good, with about average participation (which for the IPsecME WG means "the chairs had to beg a bit for more participants, but we then got them"). We also got a "TSVDIR-ish review" of the draft, which got good discussion on the list. There was a reasonable amount of give-and-take, and the WG Last Call was uncontentious. 3. Intellectual Property The author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points There are no normative downrefs. The IANA Considerations are short and to the point. The expert review for the two items there has not been done yet, but the designated expert participated in the WG Last Call, so this is not likely to be an issue. |
2014-03-13
|
06 | Valery Smyslov | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2014-03-13
|
06 | Valery Smyslov | New version available: draft-ietf-ipsecme-ikev2-fragmentation-06.txt |
2014-03-12
|
05 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2014-03-10
|
05 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2014-03-10
|
05 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-ipsecme-ikev2-fragmentation-05. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-ipsecme-ikev2-fragmentation-05. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. One of the actions requested in the IANA Considerations section requires expert review as per RFC 5996. We received the following comments/questions from the IANA's reviewer: Upon approval of this document, IANA understands that there are two actions which IANA must complete. First, in the IKEv2 Payload Types subregistry of the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at: http://www.iana.org/assignments/ikev2-parameters/ a new payload type is to be added to the registry as follows: Value: [ TBD-at-registration ] Next Payload Type: Encrypted Fragment Payload Notation: SKF Reference: [ RFC-to-be ] Second, in the Notify Message Types - Status Types subregistry also in the Internet Key Exchange Version 2 (IKEv2) Parameters registry located at: http://www.iana.org/assignments/ikev2-parameters/ a new message type is to be added to the registry as follows: Value: [ TBD-at-registration ] Notify Messages - Status Types: IKE_FRAGMENTATION_SUPPORTED Reference: [ RFC-to-be ] NOTES: 1) Currently the Notify Messages Types - Status Types registry is maintained through expert review as defined in RFC 5226. We have initiated a request and sent this to the designated expert for review. 2) A typo in the name of the sub-registry "IKEv2 Notify Message Types - Status Types" in the following text: This document also defines new Notify Message Types in the "Notify Messages Types - Status Types" registry: IKE_FRAGMENTATION_SUPPORTED There is an extra 'S' in "IKEv2 Notify Messages Types", the sub-registry's name. IANA understands that these two actions are the only ones required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2014-03-05
|
05 | Cindy Morgan | Shepherding AD changed to Kathleen Moriarty |
2014-03-05
|
05 | Tina Tsou | Request for Last Call review by OPSDIR is assigned to David Frascone |
2014-03-05
|
05 | Tina Tsou | Request for Last Call review by OPSDIR is assigned to David Frascone |
2014-03-05
|
05 | Tina Tsou | Assignment of request for Last Call review by OPSDIR to Mehmet Ersue was rejected |
2014-03-04
|
05 | Tina Tsou | Request for Last Call review by OPSDIR is assigned to Mehmet Ersue |
2014-03-04
|
05 | Tina Tsou | Request for Last Call review by OPSDIR is assigned to Mehmet Ersue |
2014-02-27
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2014-02-27
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Suresh Krishnan |
2014-02-27
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Derek Atkins |
2014-02-27
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Derek Atkins |
2014-02-26
|
05 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-02-26
|
05 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (IKEv2 Fragmentation) to Proposed Standard … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (IKEv2 Fragmentation) to Proposed Standard The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IKEv2 Fragmentation' 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 2014-03-12. 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 the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-02-26
|
05 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-02-26
|
05 | Amy Vezza | Last call announcement was generated |
2014-02-25
|
05 | Sean Turner | Placed on agenda for telechat - 2014-04-03 |
2014-02-25
|
05 | Sean Turner | Last call was requested |
2014-02-25
|
05 | Sean Turner | Ballot approval text was generated |
2014-02-25
|
05 | Sean Turner | Ballot writeup was generated |
2014-02-25
|
05 | Sean Turner | IESG state changed to Last Call Requested from Publication Requested |
2014-02-25
|
05 | Sean Turner | Last call announcement was generated |
2014-02-13
|
05 | Paul Hoffman | IETF WG state changed to Submitted to IESG for Publication |
2014-02-13
|
05 | Paul Hoffman | IESG state changed to Publication Requested |
2014-02-13
|
05 | Paul Hoffman | 1. Summary Paul Hoffman (IPsecME WG co-chair) is the document shepherd and Sean Turner is (just barely still) the responsible AD. This document describes a … 1. Summary Paul Hoffman (IPsecME WG co-chair) is the document shepherd and Sean Turner is (just barely still) the responsible AD. This document describes a method to avoid IP fragmentation in large IKEv2 messages. It shows how to perform fragmentation in IKEv2 itself, replacing them by series of smaller messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. Given that this is a protocol extension, it is meant to be a Proposed Standard. 2. Review and Consensus The WG discussion of the document was fairly good, with about average participation (which for the IPsecME WG means "the chairs had to beg a bit for more participants, but we then got them"). We also got a "TSVDIR-ish review" of the draft, which got good discussion on the list. There was a reasonable amount of give-and-take, and the WG Last Call was uncontentious. 3. Intellectual Property The author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. 4. Other Points There are no normative downrefs. The IANA Considerations are short and to the point. The expert review for the two items there has not been done yet, but the designated expert participated in the WG Last Call, so this is not likely to be an issue. |
2014-02-13
|
05 | Paul Hoffman | State Change Notice email list changed to ipsecme-chairs@tools.ietf.org, draft-ietf-ipsecme-ikev2-fragmentation@tools.ietf.org |
2014-02-13
|
05 | Paul Hoffman | Responsible AD changed to Sean Turner |
2014-02-13
|
05 | Paul Hoffman | Working group state set to Submitted to IESG for Publication |
2014-02-13
|
05 | Paul Hoffman | IESG state set to Publication Requested |
2014-02-13
|
05 | Paul Hoffman | IESG process started in state Publication Requested |
2014-02-13
|
05 | Paul Hoffman | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2014-02-13
|
05 | Paul Hoffman | Intended Status changed to Proposed Standard from None |
2014-02-13
|
05 | Paul Hoffman | Changed consensus to Yes from Unknown |
2014-02-13
|
05 | Paul Hoffman | Changed document writeup |
2014-02-13
|
05 | Paul Hoffman | Document shepherd changed to Paul E. Hoffman |
2014-02-10
|
05 | Paul Hoffman | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2013-11-06
|
05 | Yaron Sheffer | Set of documents this document replaces changed to draft-smyslov-ipsecme-ikev2-fragmentation from None |
2013-11-06
|
05 | Valery Smyslov | New version available: draft-ietf-ipsecme-ikev2-fragmentation-05.txt |
2013-10-18
|
04 | Paul Hoffman | IETF WG state changed to In WG Last Call from WG Document |
2013-10-18
|
04 | Valery Smyslov | New version available: draft-ietf-ipsecme-ikev2-fragmentation-04.txt |
2013-10-04
|
03 | Valery Smyslov | New version available: draft-ietf-ipsecme-ikev2-fragmentation-03.txt |
2013-09-09
|
02 | Valery Smyslov | New version available: draft-ietf-ipsecme-ikev2-fragmentation-02.txt |
2013-08-23
|
01 | Valery Smyslov | New version available: draft-ietf-ipsecme-ikev2-fragmentation-01.txt |
2013-07-02
|
00 | Valery Smyslov | New version available: draft-ietf-ipsecme-ikev2-fragmentation-00.txt |