[IPsec] Fwd: I-D Action:draft-nir-ipsecme-ipsecha-00.txt

2009-09-21 Thread Yoav Nir
Hi all The draft linked below is a problem statement draft about using IKEIPsec 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 A

Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP

2009-09-21 Thread Tero Kivinen
Paul Hoffman writes: Here is the edited text. Please be sure it is still correct. There is the same typo my original text had: tNAT 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

[IPsec] #22 Simultaneous IKE SA rekey text

2009-09-21 Thread Tero Kivinen
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 document

Re: [IPsec] Issue #26: Missing treatment of error cases

2009-09-21 Thread Tero Kivinen
Paul Hoffman writes: section anchor='sect-2.21' title='Error Handling' tIf 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

Re: [IPsec] AD review comments for draft-ietf-ipsecme-traffic-visibility

2009-09-21 Thread Yaron Sheffer
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

Re: [IPsec] Issue #26: Missing treatment of error cases

2009-09-21 Thread Paul Hoffman
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: tNOTE 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

Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP

2009-09-21 Thread Paul Hoffman
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 is

Re: [IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated transport mode ESP

2009-09-21 Thread Scott C Moonen
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

Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01

2009-09-21 Thread Scott C Moonen
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, with a new

Re: [IPsec] #22 Simultaneous IKE SA rekey text

2009-09-21 Thread David Wierbowski
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