I made new version of the RFC5996bis (yes, I am more than month too
late from my original time-estimate).
This version removes the Raw RSA public keys, adds reference to the
5996, 6989 and 4945. Cleans up IANA Considerations section, and adds
note to both to the abstract and Introduction that
On Thu, 17 Oct 2013, Tero Kivinen wrote:
I made new version of the RFC5996bis (yes, I am more than month too
late from my original time-estimate).
This version removes the Raw RSA public keys
Is that the old version that would be obsoleted by
draft-kivinen-ipsecme-oob-pubkey that no one
Hi Paul,
Regarding your second point, I would like to avoid feature creep in this
document. So unless there's a real good reason to add text (e.g. a new
security requirement) I would suggest not to do it. More specifically,
since this is a matter of local policy and implementations differ, we
On Oct 17, 2013, at 5:13 PM, Paul Wouters p...@cypherpunks.ca wrote:
While updating the retransmit timers in libreswan, I found no useful
information in 5996. Is that something we could add? I know it is
local policy but perhaps it would be good to add some guidance for
implementors. Do
The IPsecME WG had a virtual interim meeting last Wednesday.
It used a conference bridge at: +1 712-775-7400 run, I believe by
FreeConference.
I was unable to reach it from a number of landlines, and mobile. I got
in through GoogleTalk's outdial service, but there was significant quality
On Oct 17, 2013, at 10:27 AM, Michael Richardson mcr+i...@sandelman.ca wrote:
The IPsecME WG had a virtual interim meeting last Wednesday.
It used a conference bridge at: +1 712-775-7400 run, I believe by
FreeConference.
I was unable to reach it from a number of landlines, and mobile. I
Hi,
We would like to progress IKEv2 to Internet Standard, and the way we do
it is by re-publishing it with slight modifications (basically editing
for existing errata and adding references to documents published since
the original RFC). A draft already exists, thanks Tero [1]. If we do not
As I remember it IPv4 has a minimum packet size of 576 that won't (or at least
shouldn't be) fragmented by IP.
Mike.
Mike Sullenberger, DSE
m...@cisco.com .:|:.:|:.
Customer Advocacy CISCO
-Original Message-
From: ipsec-boun...@ietf.org
This document [1] is a product of a design team that we set up some time
ago [2]. Unfortunately it has not received enough WG review when it was
first published, but we believe it is important in extending IKE and
making it more flexible in the face of new certificate types. We would
like to
Yes, it says so in RFC 1122. Microsoft sends 576-byte packets when it does
IKEv1 fragmentation.
Still, I don't think you're going to find on the modern Internet any networks
that aren't usable by IPv6. So I think we should be pretty safe in adoption
IPv6's minimum of 1280
Yoav
On Oct 17,
Yoav,
Yes, I agree. In fact except for tunneling stealing bytes, you could likely
get away with 1500 bytes. I think that 1280 is good compromise, with perhaps a
hop down to 576 if 1280 runs into trouble.
Mike.
Mike Sullenberger, DSE
m...@cisco.com .:|:.:|:.
Customer Advocacy
The message [2] references a discussion on the list. Reading over that
discussion, I see that everyone who participated (with the exception of Scott
Fluhrer) ended up on the design team, all 5 of us. Within the design group
there was intense discussion until we settled on the encoding in the
12 matches
Mail list logo
