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
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
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
Paul Hoffman paul.hoff...@vpnc.org 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 Richardson mcr+i...@sandelman.ca 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?
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
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
On Oct 9, 2013, at 5:12 PM, Michael Richardson mcr+i...@sandelman.ca
wrote:
Michael Richardson mcr+i...@sandelman.ca 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
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 discarded.
https://www.dropbox.com/s/yn5z2n3284c0rii/draft-detienne-dmvpn-00.pdf
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Hi Yoav,
Thanks indeed for your comments! Please find additional [Fred] comments inline.
On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) manis...@cisco.com wrote:
Hi Yoav,
Thanks for your comments. I would try adding clarity to some of these
inline [Manish] to supplement what Mike said.
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
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
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
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
15 matches
Mail list logo
