CISCO
> -Original Message-
> From: Yoav Nir [mailto:y...@checkpoint.com]
> Sent: Thursday, October 17, 2013 12:09 PM
> To: Mike Sullenberger (mls)
> Cc: Valery Smyslov; ipsec@ietf.org; Paul Wouters
> Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragm
.:|:.:|:.
> Customer Advocacy CISCO
>
>
>
>> -Original Message-
>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
>> Of Valery Smyslov
>> Sent: Wednesday, October 09, 2013 10:34 PM
>> To: Paul Wouters
>> Cc: ipsec@iet
ailto:ipsec-boun...@ietf.org] On Behalf
> Of Valery Smyslov
> Sent: Wednesday, October 09, 2013 10:34 PM
> To: Paul Wouters
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-
> 03.txt
>
> >> I also think that PMTU discovery is
Yes, sure. I'm planning to do it by Friday.
Could you wrap up the last set of suggestions for more text into a -04?
That would let us do a WG LC soon.
--Paul Hoffman=
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipse
Could you wrap up the last set of suggestions for more text into a -04? That
would let us do a WG LC soon.
--Paul Hoffman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Yaron Sheffer writes:
> I'm even more worried that if we use small fragments, reliability will
> deteriorate. Because we do not have per-packet acknowledgement, and so
> if any fragment is dropped, the whole message must be resent. This is
> probably a greater risk in mobile networks.
The fix t
Sorry, I wasn't very clear. By "isn't very useful" I meant that it is
not useful
for the usual PMTU discovery goal in TCP - to find _maximum_ IP datagram
size that is not fragmented by IP level. In IKE its the goal is
different -
to find _some_reasonable_ IP datagram size that is not fragmented
Hi Paul,
o Check message validity - in particular, check whether values of
Fragment Number and Total Fragments in Encrypted Fragment Payload
are valid. If not - message MUST be silently discarded.
should be changed to say:
o Check message validity - in particular, check whethe
I also think that PMTU discovery isn't very useful for IKE.
That's why it is MAY.
That does not help implementors who still have to implement the MAY's.
if even you as a document author does not think it is veru usefil,
then I think it should just not be in the document.
Sorry, I wasn't very c
I also think that PMTU discovery isn't very useful for IKE.
That's why it is MAY.
That does not help implementors who still have to implement the MAY's.
if even you as a document author does not think it is veru usefil,
then I think it should just not be in the document.
Sorry, I wasn't very c
Paul Wouters writes:
> On Wed, 9 Oct 2013, Tero Kivinen wrote:
>
> > For example the
> >
> > o Check message validity - in particular, check whether values of
> > Fragment Number and Total Fragments in Encrypted Fragment Payload
> > are valid. If not - message MUST be silently discar
On Wed, 9 Oct 2013, Tero Kivinen wrote:
For example the
o Check message validity - in particular, check whether values of
Fragment Number and Total Fragments in Encrypted Fragment Payload
are valid. If not - message MUST be silently discarded.
should be changed to say:
o Chec
Valery Smyslov writes:
> There is no field "id" in IKEv2 Fragmentation Payload - just Fragment Number
> and Total Fragments. But Total Fragments field plays a dual role if
> peer uses PMTU discovery - i.e. tries several fragment sizes.
> In this case Total Fragments allows to distinguish between fr
On Fri, 4 Oct 2013, Valery Smyslov wrote:
So it may decide to fragment message too late. The only exception -
the situation you described, when responder always sends messages
fragmented. I think we may add this exception to responder's logic.
Okay.
I also think that PMTU discovery isn't ver
Hi Paul,
> The idea is that it is Initiator who decides whether to use
> fragmentation or not,
> as only he/she is responsible for retransmissions. Responder is just a
> "slave".
> And for simplicity we assume that either both use fragmentation or both
> don't.
> It is stated in the beginning
On Fri, 4 Oct 2013, Valery Smyslov wrote:
The idea is that it is Initiator who decides whether to use fragmentation or
not,
as only he/she is responsible for retransmissions. Responder is just a
"slave".
And for simplicity we assume that either both use fragmentation or both
don't.
It is state
Hi Yaron,
If Responder receives IKE Fragment Message after it received, successfully
verified and processed regular message with the same Message ID, it means
that response message didn't reach Initiator and it activated IKE
Fragmentation. If Fragment Number in Encrypted Fragment Payload in t
sted new version of IKEv2 Fragmentation draft.
Comparing with -02 version it clarifies Initiator's behaviour
with regard to retransmissions.
Regards,
Valery Smyslov.
- Original Message - From:
To:
Cc:
Sent: Friday, October 04, 2013 4:35 PM
Subject: [IPsec] I-D Action:
draft-ietf-ipsecme-ike
IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Security Maintenance and Extensions
Working Group of the IETF.
Title : IKEv2 Fragmentatio
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions
Working Group of the IETF.
Title : IKEv2 Fragmentation
Author(s) : Valery Smyslov
Filename: dra
20 matches
Mail list logo
