Skip to main content

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