Hi Yaron/Sean/Julien/Greg/Scott/Yoav,
Thank you very much for your comments. We are working on them and we
hope to have a new revision out soon.
Thanks
Sheila and Suresh
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ip
Yes, I will soften the language a bit, but I won't mention a DELETE payload. If
some implementations do it. others may come to expect it. We don't want to
encourage that by suggesting that it's a good idea.
On Sep 3, 2009, at 11:52 PM, Keith Welter wrote:
>If the error occurs on the
>i
>If the error occurs on the
>initiator, the notification MUST be returned in a separate
>INFORMATIONAL exchange, with no other payloads.
Should an implementation be prohibited from sending an empty delete
payload
in this case? I would prefer wording like the following:
"with no other
Kalyani Garigipati wrote:
>> One obvious approach would be not to sync after every exchange
>> (that could be a lot of messages), but sync, say, every N seconds
>> (say, N=5) in one big batch (for all IKE_SAs that changed in the
>> last N seconds).
>
> If sync is done in batches and if active d
Hi Yoav,
I agree that 2nd solution is easier to implement, but the peer will have
to delete the impending requests it might retransmit to the standby
device.
This will also not catch the message replay attacks which is the major
advantage of using message Id's
(once the window is reset, ea
Hi Pasi,
Please find replies inline.
Regards,
Kalyani
From: pasi.ero...@nokia.com [mailto:pasi.ero...@nokia.com]
Sent: Thursday, September 03, 2009 9:58 PM
To: Kalyani Garigipati (kagarigi); ipsec@ietf.org
Subject: RE: Ikev2 HA message Id Issue
On
One obvious approach would be not to sync after every exchange (that could be a
lot of messages), but sync, say, every N seconds (say, N=5) in one big batch
(for all IKE_SAs that changed in the last N seconds). Most of the time, almost
all IKE_SAs are just sitting there idle (so IKEv2 message I
Hi Kalyani
Of the two, I prefer the 2nd solution, as it is simpler. Reusing message IDs is
not that bad, and you can decrease the change by including (in the
RESET_MESSAGE_ID notification) a random number as the starting message ID.
What I'm not so sure, is that there is a real problem here th
On Thu, Sep 3, 2009 at 5:11 PM, Tero Kivinen wrote:
> Yaron Sheffer writes:
>> [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in
>> fact an early version of our work did exactly that. But the working group
>> gave us a clear direction to use a separate exchange, and this
Tero, thanks for the comments and the clarification on how to read a lower
case must. I do have a few more comments.
>So implementations cannot just search uppercase "MUST/SHOULD/MAY"
>texts and assume it is enough to make sure those are correct. It also
>needs to do what the text says...
>
I th
The IESG has received a request from the Robust Header Compression WG
(rohc) to consider the following document:
- 'IKEv2 Extensions to Support Robust Header Compression over IPsec
(ROHCoIPsec) '
as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
The IESG has received a request from the Robust Header Compression WG
(rohc) to consider the following document:
- 'Integration of Robust Header Compression (ROHC) over IPsec Security
Associations '
as an Informational RFC
The IESG plans to make a decision in the next few weeks, and soli
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org]
On Behalf Of The IESG
Sent: Thursday, September 03, 2009 16:48
To: IETF-Announce
Cc: r...@ietf.org
Subject: Last Call: draft-ietf-rohc-ipsec-extensions-hcoipsec (IPsec
Extensions to Support Robust Header Compression over I
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org]
On Behalf Of The IESG
Sent: Thursday, September 03, 2009 16:47
To: IETF-Announce
Cc: r...@ietf.org
Subject: Last Call: draft-ietf-rohc-ikev2-extensions-hcoipsec (IKEv2
Extensions to Support Robust Header Compression over I
Hi, Yaron:
Please check my response inlines:
BRG
Peny
2009/9/3 Yaron Sheffer :
> Hi Peny,
>
> Thank you for reviewing this draft. Please see my comments below.
>
> Regards,
> Yaron
>
>> -Original Message-
>> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
All in all, the qualifications of being a true retransmitted IKE
request/response message is dependent on the* post-encrypted* IKE
request/response message being bitwise identical. Naoyoshi, if you don't
mind me asking, which implementation are observing this behavior from (I'm
not sure if this br
From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org]
On Behalf Of The IESG
Sent: Thursday, September 03, 2009 16:47
To: IETF-Announce
Cc: r...@ietf.org
Subject: Last Call: draft-ietf-rohc-hcoipsec (Integration of Robust Header
Compression (ROHC) over IPsec Security Associati
Hi ,
In Ikev2 HA, there is an issue with the message Id and window size.
Standby device---active
device--Peer device
The active device participating in the exchange with the peer will
update its message id counters as per the exchanges
Paul Hoffman writes:
> At 3:50 PM +0300 8/24/09, Tero Kivinen wrote:
> >So would this text be added to both documents or what?
>
> It should go in both. That way, an implementer a year from now who
> comes across one of the RFCs will both find out about the other and
> be clear on the relationship
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 : Heuristics for Detecting ESP-NULL packets
Author(s) : T. Kivinen, D. McDonald
Yaron Sheffer writes:
> [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in
> fact an early version of our work did exactly that. But the working group
> gave us a clear direction to use a separate exchange, and this is where we
> disagree: I believe we did have a strong WG
internet-dra...@ietf.org writes:
> Title : Wrapped ESP for Traffic Visibility
> Author(s) : K. Grewal, et al.
> Filename: draft-ietf-ipsecme-traffic-visibility-08.txt
> Pages : 15
> Date: 2009-09-01
Found out one more nit
David Wierbowski writes:
>
> In a recent append Tero said:
>
> >Then the responder is already going against the RFC4306 which says
> >"Certificate revocation checking must be considered during the
> >chaining process used to select a certificate. " meaning the responder
> >cannot send certifiate
23 matches
Mail list logo
