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
Hi Tero,
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 betw
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
Are at
http://www.ietf.org/proceedings/interim/2013/10/09/ipsecme/minutes/minutes-interim-2013-ipsecme-2
And a recording is at http://www.vpnc.org/ipsecme-virtual-interim-2013-10-09.mp3
Participants: please let me know if I messed up any of the notes
Everyone: if you want to comment on anything
While we are updating the algorithm requirements for the ESP and AH, I
think we should also update the RFC4307 too at the same time, as a
separate document.
I think the changes we would like to do there are:
Downgrade Diffie-Hellman group 2 (1024-bits) from MUST- to SHOULD.
Upgrade Diffie-Hellman
Hi Yoav,
Thanks indeed for your comments! Please find additional [Fred] comments inline.
On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) wrote:
> Hi Yoav,
>
> Thanks for your comments. I would try adding clarity to some of these
> inline [Manish] to supplement what Mike said.
>
> Manish
>
https://www.dropbox.com/s/yn5z2n3284c0rii/draft-detienne-dmvpn-00.pdf
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
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 Oct 9, 2013, at 5:12 PM, Michael Richardson
wrote:
>
> Michael Richardson wrote:
>>> The call-in details are:
>>> Tele: +1 712-775-7400
>>> Code: 809604#
>
>mcr> Two LD suppliers (entirely different phones) tell me that I can not
> reach
>mcr> this number from my line.
>
> I won
I tried to read this before the interm meeting, but found out that it
would require me to read it trough several times before I could really
understand it.
The basic architecture is simple, we have some trusted third party,
ADS which stores all information and ADC devices talk to it and gets
some
The new SEQ-ICV calculation is no more safer than the previous one. It
is trivial to break it:
SEQ-ICV = (SEQ + ICV[0-3]) ^ K[0-3] +
(SEQ + ICV[4-7]) ^ K[4-7] +
(SEQ + ICV[8-11]) ^ K[8-11]
The problem is that lowest byte of the SEQ-ICV only depends on the
K[3]
Michael Richardson wrote:
>> The call-in details are:
>> Tele: +1 712-775-7400
>> Code: 809604#
mcr> Two LD suppliers (entirely different phones) tell me that I can not
reach
mcr> this number from my line.
I wonder if this exchange has an inflated LD rate?
Nice if there was
Paul Hoffman wrote:
> The call-in details are:
> Tele: +1 712-775-7400
> Code: 809604#
Two LD suppliers (entirely different phones) tell me that I can not reach
this number from my line.
I'm gonna try Google Talk now.
(and I guess it's really in an hour anyway)
--
Michael Richards
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
In section "2.2. Verifying the HAND_OVER_CHILD_SAS Notification" the
document lists operations which needs to be done when handling the
notification. The process seems otherwise quite good, expect the error
handling seems to be bit drastic.
It currently says that if the authenticated identites are
18 matches
Mail list logo
