Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-04-01 Thread Panwei (William)
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

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-04-01 Thread Michael Richardson
Panwei (William) wrote: > It seems to me that extending the traceroute by using an ESP packet can > be done right now and has no requirement for the ESP packet format. Any > ESP packets can work with this mechanism, and there is no need for the > designated SPIs. > The

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-04-01 Thread Panwei (William)
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

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-03-27 Thread Michael Richardson
Panwei (William) 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. No, only the final machine. Others would respond with ICMP unreachable when TTL=0 -- Michael Richardson , Sandelman Software Works

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-03-27 Thread Michael Richardson
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 meant to extend traceroute to use an ESP packet instead > of an ICMP or UDP packet. The machines in the

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-03-27 Thread Kan-Ru Chen
Hi, On Wed, Mar 27, 2024, at 8:24 PM, Panwei (William) wrote: > Thanks for your and Michael’s clarifications. I’m much clearer now and I’m > convinced this is an useful draft. > I think it would be useful to add one or two sentences in the introduction. > An example is given below. > >

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-03-27 Thread Paul Wouters
On Wed, 27 Mar 2024, Panwei (William) wrote: 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

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-03-27 Thread Panwei (William)
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? >

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-03-27 Thread Panwei (William)
.org WG ; Michael Richardson Subject: Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt Yes, the idea is to make it possible to leverage native ESP. Pretty much all IPv6 networks (at least commercial networks) don't do NAT. But some of them drop ESP pac

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-03-27 Thread Michael Richardson
Panwei (William) 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

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-03-26 Thread Lorenzo Colitti
Linkova > > Sent: Thursday, February 29, 2024 11:28 PM > > To: ipsec@ietf.org > > Cc: Lorenzo Colitti ; Michael Richardson > > > > Subject: [IPsec] Fwd: New Version Notification for > > draft-colitti-ipsecme-esp-ping-01.txt > > &g

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-03-26 Thread Panwei (William)
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*

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-03-26 Thread Michael Richardson
Panwei (William) wrote: > I feel that the problem of IPv6 ESP traverse failure, as described in > the draft and presentation slides, is because of NAT. IKEv2 already I'm not sure I understand how you get this from the Problem Statement. Clearly, we need to clarify the purpose. It's not

Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-03-26 Thread Panwei (William)
Subject: [IPsec] Fwd: New Version Notification for > draft-colitti-ipsecme-esp-ping-01.txt > > -01 version shall address comments received since -00. > The main change is that payload format is defined similarly to ICMPv6 > echo, and the draft now updates RFC4303,

[IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt

2024-02-29 Thread Jen Linkova
-01 version shall address comments received since -00. The main change is that payload format is defined similarly to ICMPv6 echo, and the draft now updates RFC4303, so ESP packets with SPI == 7 or 8 and next header==59 are not considered to be dummy packets. Comments are appreciated!