Hello all,
I have a question regarding proper choosing of traffic selectors in the
situation where an initator is behind a NAT device. Let us use the following
scenario:
[initia...@a]--[nat@x][respon...@y]
Say A is 192.168.2.22, X is 192.168.3.5 and Y is 192.168.4.25, and all hav
Paul Hoffman writes:
> 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
> 3
Scott C Moonen writes:
> > 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 payload when the error is sent in a
> > separate INFORMATIONAL exchange. Do we want to allow such addit
Scott C Moonen writes:
> - Is Section 1.2 necessary? None of these terms are used in this fashion
> in this document.
True. Removed.
> - page 8, "sees an new" => "sees a new"
> - page 8, "in the Section 8" => "in Section 8"
Fixed.
> - page 12, excessive space in "i.e. UDP encapsulated"; per
David Wierbowski writes:
> I see no reason why Host A MUST NOT immediately delete the old IKE SA.
Deleting the IKE SA immediately makes it impossible to know what
happened to other exchanges going on the same IKE SA. Waiting for 30
seconds or so after rekey would allow those other exchanges to fin
Matthew Cini Sarreo writes:
> Hello all,
>
> I have a question regarding proper choosing of traffic selectors in the
> situation where an initator is behind a NAT device. Let us use the following
> scenario:
>
> [initia...@a]--[nat@x][respon...@y]
>
> Say A is 192.168.2.22, X is
I support advancing this document, and I think the explanations and
pseudo code are good.
I do, however, question the value of it in real life.
Security policies or the deep inspection kind usually are something
like:
- allow HTTP and HTTPS, and verify headers
- allow ICMP and DNS
- may
Hi,
I have uploaded everything to the wiki:
http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/Interim20090922
See you all later.
Yaron
Email secured by Check Point
Email secured by Check Point
___
IPsec mailing list
IPsec@ietf.org
https://www.
>Tero Stated:
>
> Deleting the IKE SA immediately makes it impossible to know what
> happened to other exchanges going on the same IKE SA. Waiting for 30
> seconds or so after rekey would allow those other exchanges to finish
> before the old IKE SA is deleted.
>
> The current IKEv2 docum
I posted this a last week and have not seen any comments:
Section 3.6 of ikev2bis-04 says, "Certificate payloads SHOULD be included
in an exchange if certificates are available to the sender unless the peer
has indicated an ability to retrieve this information from elsewhere using
an HTTP_CERT_L
Comments inline, thanks
2009/9/3 Tero Kivinen :
> 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
Hi Hui,
Thank you for your comments. Regarding your second comment, please see
http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-resumption-08#section-9.4
Regards,
Yaron
> -Original Message-
> From: Hui Deng [mailto:denghu...@gmail.com]
> Sent: Tuesday, September 22, 2009 17:4
Tero, I don't understand. Two weeks ago you said:
> If you use that kind of halfway up IKE SA for sending INFORMATIONAL
> message to other end (who thinks the IKE SA is up and valid), then I
> agree that sending both N(AUTHENTICATION_FAILED) and DELETE would be
> the correct way to do it. DELETE
Hi Matt. Our implementation works a little differently from Tero's, so
I'm replying just to provide a different perspective.
For our implementation, we've decided that foreign network addresses
should not generally appear in either our configuration or our primary
displays. In your scenario,
On Tue, Sep 22, 2009 at 12:52:51PM -0400, Scott C Moonen wrote:
> Hi Matt. Our implementation works a little differently from Tero's, so
> I'm replying just to provide a different perspective.
> Our design decision does prevent our implementation from initiating to a
> remote IPsec gateway if
Dan,
> Your design (which is similar to the one in Solaris/OpenSolaris) WOULD
allow
> initiation to a behind-a-NAT peer if (and only if) the NAT was smart
enough
> to redirect 500 and 4500 to a single entity inside its private network.
> (I'll be experimenting with this directly when I move into
16 matches
Mail list logo
