Hi Valery,
Thank you very much for your review.
We agree with all these issues you pointed out, and we'll address them in the
next version.
Regards & Thanks！
Wei PAN (潘伟)
> -Original Message-
> From: IPsec On Behalf Of Valery Smyslov
> Sent: Friday, May 3, 2024 8:51 PM
Thanks for adding the use cases section, it's useful to me.
In section 5, after adding the third scenario of not receiving the ESP Echo
Reply packet, there are two points in the following paragraph that also need
adjustments.
1. s/the sender can not distibguish those two scenarios/the sender
Michael Richardson wrote:
> Yes, that's true up to the final hop.
> At the final hop, when the destination address is local, then one *might*
> receive an ICMP Parameter Problem because the SPI is not recognized.
> Maybe.
> If it does not, then the sender will send another
Hi Paul and Michael, thanks for your explanations.
Michael Richardson wrote:
> Paul Wouters wrote:
> > > If you want to do the traceroute to determine how far ESP
> > > actually gets, you need to make sure every node supports
> > > the ESPping.
> >
> > I think people
Hi Michael,
Thanks for your clarification. I'm much clearer about the problems now.
> > When you find out that the IKEv2 negotiation succeeds but ESP
> > traffic can't get through, what more information will you get
> > from sending the ESPping and not receiving a response?
>
will by
default use unencapsulated IPv6 ESP.
This leads to the IPsec session not being able to exchange any
packets even though IKE negotiation succeeded.
Regards & Thanks！
Wei PAN (潘伟)
From: Lorenzo Colitti
Sent: Wednesday, March 27, 2024 12:07 PM
To: Panwei (William)
Cc: Jen Linkova ; ipsec@ietf
Michael Richardson wrote:
> I'm not sure I understand how you get this from the Problem
> Statement.
> Clearly, we need to clarify the purpose.
> It's not about detecting NAT, it's about determining if ESP will work or
> not.
> It's not about detecting or avoiding *NAT*
Hi,
I've read the draft and I think I can understand the solution part. But please
allow me to ask a stupid question about the motivation or use case, because I'm
a little confused about that.
I feel that the problem of IPv6 ESP traverse failure, as described in the draft
and presentation
Hi Michael,
> > At yesterday's meeting, I think people basically understood and
> > accepted the problem statement itself, but also raised different
> > ideas regarding to the solutions. We'll try to do more analysis
> > and comparison of possible solutions,
s！
Wei PAN (潘伟)
> -Original Message-
> From: Steffen Klassert
> Sent: Friday, March 15, 2024 5:31 PM
> To: Paul Wouters
> Cc: Panwei (William) ; ipsec@ietf.org WG
>
> Subject: Re: [IPsec] I-D Action:
> draft-he-ipsecme-vpn-shared-ipsecsa-00.txt
Hi Paul,
Thanks for your quick comments. But I'm sorry for the late response due to I
was out of the office for a few days.
> I can see how you want an extra SPD selector for the VPN ID - but
> maybe call it Namespace ID or something else as VPN ID is confusing.
Thanks for pointing out
Hi folks,
We've encountered a real problem when using IPsec in the Multi-VPN environment.
We find that separate IPsec tunnels (i.e., different IKE SAs and different
Child SAs) are needed for each VPN to distingue the traffic from different VPNs.
But, due to the number of peer devices and the
Hi folks,
As a follow-up of the previous discussion about ESN and anti-replay
entanglement problem, we've prepared a draft:
https://datatracker.ietf.org/doc/draft-pan-ipsecme-anti-replay-notification/
The current draft mainly wants to highlight the problem.
It also gives a preliminary solution
ithout reply".
Regards & Thanks！
Wei PAN (潘伟)
> -Original Message-
> From: Paul Wouters
> Sent: Tuesday, February 6, 2024 3:01 AM
> To: Panwei (William)
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] What's the most reasonable way for the respond
Hi Tero,
Thank you very much for your feedback. I'm glad to see that your thoughts
concur with mine. It really helps.
Regards & Thanks！
Wei PAN (潘伟)
> -Original Message-
> From: Tero Kivinen
> Sent: Tuesday, February 6, 2024 2:52 AM
> To: Panwei (Wi
Hi folks,
Several new Key Exchange methods were defined after RFC 7296 was published.
(See
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8)
For example, RFC 8031 introduced two new KE methods, Curve25519 (KE Method ID =
31) and Curve448 (KE Method ID
Hi,
We are facing the same problem, too. We were planning to construct an email to
the list, and we're happy to find that we're not alone.
> -Original Message-
> From: IPsec On Behalf Of Steffen Klassert
>
> > On Wed, Jan 03, 2024 at 03:40:52PM -0500, Paul Wouters
Hi,
I support the adoption of this draft.
I've read the very early version and thought it was quite useful.
I've read it again and still believe it's important and useful. I believe we're
highly likely to implement this draft.
Some quick comments below:
1) I feel the title "Alternate
Hi Daniel,
Thanks for your clarification, I think I may have better understanding of your
problem statement. I try to give an example below, please correct me if I’m
wrong.
First, let’s assume the encryption/decryption capability of ingress node is
15000 bytes and the capability of egress
Hi,
I've read this draft and support the adoption.
Regards & Thanks!
Wei PAN (潘伟)
> -Original Message-
> From: IPsec On Behalf Of Tero Kivinen
> Sent: Thursday, November 10, 2022 1:35 AM
> To: ipsec@ietf.org
> Subject: [IPsec] IPsecME WG Adoption call for
>
Hi chairs & folks,
We’d like to ask for 5 minutes for IKEv2 Optional SA Payloads in Child
Exchange (draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt).
We updated a new version to fix some typos. We authors think the draft is
mature and would like to ask the WG to consider adopting it this time.
Hi authors,
I’ve read the recent version. This is an interesting solution. I think it
should be adopted. Below are some comments.
1.
The CPU_QUEUES notification value refers to the number of additional
resource-specific Child SAs that may be installed for this particular
TSi/TSr combination
> To: Panwei (William)
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] I-D Action:
> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt
>
> On Mon, 5 Jul 2021, Panwei (William) wrote:
>
> Hi Wei Pan,
>
> > According to the discussion on the mailing list, I update
Hi,
According to the discussion on the mailing list, I update the draft to version
05. In this version, I deleted the unnecessary considerations for the
configuration changes. For now, the solution is very simple and just includes
the negotiation at creating IKE SAs and optimization at
Paul Wouters On Wednesday, June 9, 2021:
> To: Panwei (William)
> Cc: antony.ant...@secunet.com; ipsec@ietf.org
> Subject: Re: [IPsec] FW: I-D Action:
> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt
>
> On Wed, 9 Jun 2021, Panwei (William) wrote:
>
>
&
om]
> Sent: Wednesday, June 9, 2021 8:01 PM
> To: Panwei (William)
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] FW: I-D Action:
> draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt
>
> Hi,
> I am happy to see this draft progressing. I am wonder why allow changes
> on
Hi Chairs, folks,
I've updated a new version of draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt.
It's not a big update. I've received many good comments online/offline before.
I tried to address some of them, and there are still several comments under
consideration.
This draft tries to
Hi,
I support adoption of this draft.
Regards & Thanks!
Wei Pan
-Original Message-
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen
Sent: Monday, March 8, 2021 10:22 PM
To: ipsec@ietf.org
Subject: [IPsec] WG ADoption call for draft-pwouters-ikev1-ipsec-graveyard
> -Original Message-
> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Wouters
> Sent: Wednesday, March 3, 2021 2:56 AM
> To: Tero Kivinen
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] IPsecME agenda for IETF-110
>
> On Tue, 2 Mar 2021, Tero Kivinen wrote:
>
> >> Can we talk
Hi Valery,
It seems like a rare scene but I think it needs to be considered.
Compared with ignoring cookie payload, how about adding N(COOKIE2) in the 9th
message? Then when Initiator received the 12th message, it'll know which cookie
this message matches with.
Regards & Thanks!
Wei Pan
>
Hi,
I've updated the IKEv2 rekeying optimization draft.
In the new version, IKE SAs rekeying optimization is optional now. It's up to
the implementer to optimize the IKE SAs rekeying or not.
And the optimization processes are also simplified to two cases (before was
three cases):
- The
;Re: Contents of IPsec digest..."
Today's Topics:
1. Fwd: New Version Notification for
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt
(Panwei (William))
----------
Message: 1
Date: Wed, 22 May 2019 07:3
...@ietf.org]
Sent: Wednesday, May 22, 2019 2:17 PM
To: Meduri S S Bharath (A) ; Meduri S S Bharath (A)
; Panwei (William) ;
Sandeep Kampati
Subject: New Version Notification for
draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt
A new version of I-D, draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt
33 matches
Mail list logo
