Subject: [IPsec] Comments to the draft-smyslov-ipsecme-ikev2-fragmentation-00.txt

From: Tero Kivinen <[email-masked]>
Date: Sun, 4 Nov 2012 04:37:55 +0200

A general comment: I think we already decided in the WG that we will
go with the tcp approach, not with this fragmentation layer in the
IKEv2. Why do we have this document here?

Some other comments

In section 2.5 the header contains "Total Framgments" field. This
means the initiator must decide the number of framents it is sending
out in the beginning, i.e. it cannot dynamically adjust this if it
sees that it is sending so long fragments that they get lost. It would
be better to use standard way of doing this, i.e. sending the offset
to the start of the fragment, and some kind of indication whether this
was last fragment or not.

Also it is not clear how retransmission is done here at all. I assume
we will send all fragments in case of the retransmission, but again we
cannot adjust the fragment size to be smaller, even if we start to
suspect that there is something between which is eating our fragments.
Only way to do that would be to delete the IKE SA and start over with
lower fragment size parameter (as it is possible that the responder
did got some of the fragments, for example last one, which was small
enough, and as we only have fragment number, not offset we cannot
know at which offset that packet belongs to). 
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 4 Nov 2012 08:29:29 -0500

> IKEv2. Why do we have this document here?

We don't. Documents listed as "Related Documents" on the Datatracker page are just that: related. They are not WG work items.

--Paul Hoffman

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 4 Nov 2012 07:35:08 -0800 (PST)

On Sun, November 4, 2012 5:29 am, Paul Hoffman wrote:
> We don't. Documents listed as "Related Documents" on the Datatracker page
> are just that: related. They are not WG work items.

  Can IKEv3 be added to the related documents section?

  Thanks,

  Dan.

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 4 Nov 2012 18:30:32 +0200

Paul Hoffman writes:
> We don't. Documents listed as "Related Documents" on the Datatracker
> page are just that: related. They are not WG work items. 

Ah, I misremembered in the plane then when I was reading this. I
tought this was on the agenda for the ipsecme meeting on monday... On
the other hand the ikev3 draft was not listed in the related
documents, as it does not have -ipsecme- in its name, which caused
that my sec-area WG ebook containing all WG and WG related drafts and
RFC did not include it... Need to read it now... 
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 04 Nov 2012 19:50:52 +0200

As Tero mentioned on another thread, the "related docs" section is 
created automatically based on keyword matching. You'll need to rename 
the I-D to draft-harkins-ipsecme-ikev3.

Thanks,
	Yaron

On 11/04/2012 05:35 PM, Dan Harkins wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 5 Nov 2012 10:18:13 +0400

Hi Tero, thank you for your comments.

> IKEv2. Why do we have this document here?

As others pointed out this draft is not a WG item.

> was last fragment or not.

Sorry, I see no difference here. Currently draft doesn't allow fragment size
to be adjusted dynamically, as it is easier to implement. But in general
it is possible. When initiator suspects fragments are too big, it would
refragment original packet using smaller value. That will effectively
change fragments number field, that will give responder an indication,
that this is other set of fragments, which will be reassembling in different
fragments list. 

> we will send all fragments in case of the retransmission, but again we

Exactly.

> suspect that there is something between which is eating our fragments.

See above.

> know at which offset that packet belongs to). 

Even if responder knew offset, what would be the difference?

Regards,
Valery Smyslov.