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 Session Resumption
Author(s) : Y. Sheffer, H. Tschofenig
Filena
Hi all
The draft linked below is a problem statement draft about using
IKE&IPsec implementations in high availability and load sharing
configurations.
I will describe this at tomorrows Interim meeting.
Comments are welcome, of course, both on the list and at tomorrow's
session.
Yoav
>
>
Grewal, Ken writes:
> >- A question: did the WG discuss the pros and cons of integrity
> >protecting the WESP header? (This does make WESP more complex to
> >implement, and currently the WESP header does not contain any data
> >that would benefit from integrity protection in any way.)
> [Ken] This
Paul Hoffman writes:
> Here is the edited text. Please be sure it is still correct.
There is the same typo my original text had:
> NAT A will then replace the source address of the IKE packet from
> IP1 to IPN2, and NAT B will replace the destination address of the IKE
This should
Paul Hoffman writes:
> #22 - Add section on simultaneous IKE SA rekey
> There was no discussion. We will bring this up one more time
> because it is important, but if there is not more interest and
> more inclination to review Tero's text, we will write a short
> note in the documen
Paul Hoffman writes:
>
>
> If there is an error parsing or processing a response packet, the
> general rule is to not send bac any error message because responses
^^^
s/bac/back/
> should not generate new requests (and a new request would be the only
> way to send b
Hi Tero,
Given that the existing ESP header is integrity-protected, I don't see the
downside to adding the same protection for the new header. On the other hand,
this would eliminate a whole class of vulnerabilities. We still have a few
reserved bits in the WESP header, and you don't want to fi
Just a reminder that the meeting is tomorrow, in about 24 hours. See/hear you
there!
At 7:53 PM -0700 9/17/09, Paul Hoffman wrote:
>At 10:03 PM +0300 9/12/09, Yaron Sheffer wrote:
>> The ipsecme WG will have a virtual interim WG meeting in about a month. We
>> will have a conference call on Tuesd
Thanks for the two editorial notes; fixed.
We want more input on the following:
At 3:28 PM +0300 9/21/09, Tero Kivinen wrote:
> > NOTE FOR WG DISCUSSION: Having other payloads in the message is
>> allowed but there are none suggested. One WG member mentioned the
>> possibility of adding a DELETE
At 2:49 PM +0300 9/21/09, Tero Kivinen wrote:
>The IP addresses are also needed for the RFC 3948 incremental checksum
>fixup in udp encapsulation, not only for undoing the address
>substitution.
As I said in my earlier note, I have removed all discussion of RFC 3948 from
this new text. RFC 3948 i
Paul,
> between wanting to help the peer to diagnose a problem and thust
s/thust/thus/
> wanting to avoid being part a denial of service attack
Suggest either "being part *of* a" or "being a willing participant in a".
> NOTE FOR WG DISCUSSION: Having other payloads in the message is
> allowed
Paul,
> NAT B does not necessarely need
s/necessarely/necessarily/
> replaces the IP address in TSi payloads . . .
> replaces the IP addresses in the TSr payloads . . .
> it will thus send back traffic selectors having IPN1 and IP2 as their IP
addresses . . .
. . .
As it seems there is no sup
Here are my comments:
- Is Section 1.2 necessary? None of these terms are used in this fashion
in this document.
- page 8, "sees an new" => "sees a new"
- page 8, "in the Section 8" => "in Section 8"
- page 12, excessive space in "i.e. UDP encapsulated"; perhaps replace
with comma.
- page 16,
>Tero states:
> The basic case is where both ends notice this is simultaneous
> rekey, and can delay moving of the CHILD_SAs until they know which
> one wins. The more complex case happens where there is dropped
> packets and one end does not detect simultaneous rekey until it has
> already f
I agree with Dave Wierbowsk, deletion will still occur (for the old IKE SA)
so deleting it while Host B is retransmitting (or waiting for some timer to
retrasmit) seems to make most sense. Host B notices the delete payload (or
NO_ADDITIONAL_SAS), stops retransmitting the request and go on as if the
15 matches
Mail list logo
