Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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 packet with TTL one > larger, and then when it gets no reply try again with two larger, etc. > > Receiving ESPping reply with SPI=8, would be a positive reply that the > path was clear (in both directions!). I just wondered if there is a mechanism that doesn't rely on making changes at the on-path router/firewall and the final IPsec peer. It seems there is no such a perfect mechanism (no changes required except on the sender). The final IPsec peer may indeed not reply any ICMP packets when it doesn't recognize the SPI (and this is highly possible). Therefore, the host can't know whether the ESP packet reaches the final IPsec peer. Maybe comparing the result of ESP traceroute and the one of UDP traceroute can find something to deduce the ESP packet reaches the final IPsec peer, but this isn't guaranteed. Besides that, even though the final IPsec peer replies an ICMP packet to the host, the host can only know the ESP packet can traverse in the direction from the host to the IPsec peer, but doesn't know whether the reverse direction also works. (BTW, I'd like to know the test results of this extended traceroute mechanism in the real world, if someone would do such tests.) ESP-ping can be an explicit way to find out the path is clear in both directions. It just has a prerequisite that both parties support the ESP-ping and both know that the other party supports it. > One thing which the document does not say, and I'm not sure what to > say, is what the TTL of the ESP reply ought to be. > I was contemplating if it should copy the TTL of the incoming packet. > That would weirdly let one traceroute in the reverse direction too, only > the ICMPs would go to the receiving host, which is not the host doing > the traceeroute, so not very useful actually. The TTL of the packet received by the final IPsec peer isn't the original TTL sent by the host, and its value is the original TTL minus the number of on-path routers. So, the TTL of the ESP reply may out of the scope of this draft and just be the decision of the IPsec peer's local policy, such as a default TTL. Regards & Thanks！ Wei PAN (潘伟) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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 receiver will send back an ICMP response when it receives the ESP > packet with TTL=0, no matter what this ESP packet actually looks > like. The receiver can be the on-path firewalls or routers, and the > final IPsec peer. 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 packet with TTL one larger, and then when it gets no reply try again with two larger, etc. Receiving ESPping reply with SPI=8, would be a positive reply that the path was clear (in both directions!). One thing which the document does not say, and I'm not sure what to say, is what the TTL of the ESP reply ought to be. I was contemplating if it should copy the TTL of the incoming packet. That would weirdly let one traceroute in the reverse direction too, only the ICMPs would go to the receiving host, which is not the host doing the traceeroute, so not very useful actually. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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 meant to extend traceroute to use an ESP packet > > instead of an ICMP or UDP packet. The machines in the middle > > do not need any special support because any packet that hits > > TTL=0 should solicite an ICMP response. > > That's right, and we yeah, we can do that immediately. > Perhaps obviously: The responding server needs to implement this > protocol in order to get a reply though. 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 receiver will send back an ICMP response when it receives the ESP packet with TTL=0, no matter what this ESP packet actually looks like. The receiver can be the on-path firewalls or routers, and the final IPsec peer. So, the IPsec sender can determine that the ESP packet can pass through to the IPsec peer by using this extended traceroute mechanism and successfully receiving the ICMP response from the final IPsec peer. For the purpose of testing the results of ESP packets traversing the network prior to IKE negotiation, is this extended ESP traceroute mechanism enough to use? Is it still necessary to define the ESP-ping mechanism? Regards & Thanks！ Wei PAN (潘伟) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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 -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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 middle do not need any > special support because any packet that hits TTL=0 should solicite > an ICMP response. That's right, and we yeah, we can do that immediately. Perhaps obviously: The responding server needs to implement this protocol in order to get a reply though. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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. > >However, because ESP packets do not share fate with IKE packets, it >is possible for the network to allow IKE packets but not ESP packets. > For example, the on-path firewall may allow UDP packets but discard ESP > packets, and IKE negotiation isn’t able to detect this. When NAT function is > not used as well, which is common in IPv6 networks, the IPsec session 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. > I wonder if ESP-ping can solve the opposite problem. It is also possible that because IKE and ESP are not tracked as same connection, on-path firewall may allow initial IKE SA setup and ESP to flow, but disallow rekeying. It is common in IPv6 networks to use unencapsulated IPv6 ESP, so the flow does not keep the UDP port used by IKE open. See https://github.com/strongswan/strongswan/issues/1759 for examples of this problem. I'm just a user amused by the fact that IPsec now works better on IPv4 than IPv6. Please excuse me if this is not a place to raise this question. Kan-Ru ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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 receiving a response? > > That there is a problem with proto=50... So: > a) do UDP encap (maybe by manual config, if you are clueful) > b) call network support and file a problem report. I mean, when you find out that the IKEv2 negotiation succeeds but ESP traffic can't get through, you can already guess there may be a problem with ESP packet. Waiting for failure and timeouts afterwards, eg once the IPsec SA is up, is costly and now you have to try to setup udp-encap or try ipv4. The idea is to send an ESP-ping beforehand to your server that is known to support this, and test for a reply. If you don't get it, initiate IKEv2 using IPv4 (basically also guaranteeing NAT and UDP-encap), not native IPv6. If you want to use ESPping to determine the problem is really because of the on-path firewalls or routers discard the ESP packets, you need to make sure the IPsec peer also supports the ESPping. It would be part of the client configuration I guess to try this. 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 middle do not need any special support because any packet that hits TTL=0 should solicite an ICMP response. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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? > > That there is a problem with proto=50... So: > a) do UDP encap (maybe by manual config, if you are clueful) > b) call network support and file a problem report. I mean, when you find out that the IKEv2 negotiation succeeds but ESP traffic can't get through, you can already guess there may be a problem with ESP packet. If you want to use ESPping to determine the problem is really because of the on-path firewalls or routers discard the ESP packets, you need to make sure the IPsec peer also supports the ESPping. If you want to do the traceroute to determine how far ESP actually gets, you need to make sure every node supports the ESPping. Regards & Thanks！ Wei PAN (潘伟) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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. However, because ESP packets do not share fate with IKE packets, it is possible for the network to allow IKE packets but not ESP packets. For example, the on-path firewall may allow UDP packets but discard ESP packets, and IKE negotiation isn’t able to detect this. When NAT function is not used as well, which is common in IPv6 networks, the IPsec session 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.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 packets. On these networks, NAT detection will say there is no NAT, and the ESP session will be established, but no traffic will flow. On Tue, Mar 26, 2024 at 6:24 PM Panwei (William) mailto:william.pan...@huawei.com>> wrote: 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 slides, is because of NAT. IKEv2 already supports the detection of NAT. After the detection of NAT, the peers can use IP + UDP (4500) + ESP to traverse the NAT. Are there some use cases that this existing solution doesn't work and this draft tries to solve? Or, are there some use cases that IKEv2 fails in detecting the existence of NAT? I can understand the advantages of native ESP described in the draft: 1) no keepalives or fewer keepalives, 2) no overhead of UDP header. Does this draft target the use cases where IP + UDP + ESP and IP + ESP can both work in the existence of NAT, and try to benefit from the native ESP? Regards & Thanks！ Wei PAN (潘伟) > -Original Message- > From: IPsec mailto:ipsec-boun...@ietf.org>> On Behalf Of Jen Linkova > Sent: Thursday, February 29, 2024 11:28 PM > To: ipsec@ietf.org<mailto:ipsec@ietf.org> > Cc: Lorenzo Colitti mailto:lore...@google.com>>; Michael Richardson > mailto:mcr%2bi...@sandelman.ca>> > 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, so ESP packets with SPI == 7 > or 8 and next header==59 are not considered to be dummy packets. > > Comments are appreciated! > > > -- Forwarded message - > From: mailto:internet-dra...@ietf.org>> > Date: Fri, Mar 1, 2024 at 2:24 AM > Subject: New Version Notification for > draft-colitti-ipsecme-esp-ping-01.txt > To: Jen Linkova mailto:furr...@gmail.com>>, Lorenzo Colitti > mailto:lore...@google.com>>, Michael Richardson > mailto:mcr%2bi...@sandelman.ca>> > > > A new version of Internet-Draft draft-colitti-ipsecme-esp-ping-01.txt > has been successfully submitted by Jen Linkova and posted to the IETF > repository. > > Name: draft-colitti-ipsecme-esp-ping > Revision: 01 > Title:ESP Echo Protocol > Date: 2024-02-29 > Group:Individual Submission > Pages:7 > URL: > https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.txt > Status: > https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/ > HTML: > https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-colitti-ipsecme-esp-ping > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-colitti-ipsecme-esp-ping- > 01 > > Abstract: > >This document defines an ESP echo function which can be used to >detect whether a given network path supports IPv6 ESP packets. > > > > The IETF Secretariat > > > > > -- > Cheers, Jen Linkova > > ___ > IPsec mailing list > IPsec@ietf.org<mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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 *NAT* per-se. >> We prefer not to have to encapsulate. > Please forgive my ignorance of the scenarios. My understanding is that > ESP failure is usually because of the existence of NAT. > Do you mean ESP may not work even if there is no NAT between the two IPsec peers? > If yes, I'd like to know more about how ESP failed and in what kind of > situations ESP will fail. usually, a bad firewall. One that allows UDP traffic (port 500/4500), but not proto=50. For IPv4, there will often be NAT, so the proto=50 firewall doesn't matter, as one has to UDP encap anyway. >> I think that you are over-estimating the competency of some operators: >> the experience with IPv6 is often not there. >> Even when it is, not all equipment vendors are equally competent at >> implementing/documenting things. > Is this problem, i.e., IKE works but ESP doesn't work, only exist in > the IPv6 network? Does IPv4 network have the same problem? Yes. It could exist in IPv4, and I've seen it, but NAT44 means you seldom notice. > Second, will UDP encapsulated ESP get through in these circumstances? Probably. >> The purpose of this protocol is to allow that debugging. >> The network operator people, who are not allowed into the billing >> system, can instead use an ESPping utility to send ESP traffic, adjusting >> their firewalls until they understand that UDP!=ESP. > 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? That there is a problem with proto=50... So: a) do UDP encap (maybe by manual config, if you are clueful) b) call network support and file a problem report. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* signature.asc Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
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 packets. On these networks, NAT detection will say there is no NAT, and the ESP session will be established, but no traffic will flow. On Tue, Mar 26, 2024 at 6:24 PM Panwei (William) wrote: > 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 slides, is because of NAT. IKEv2 already supports > the detection of NAT. After the detection of NAT, the peers can use IP + > UDP (4500) + ESP to traverse the NAT. Are there some use cases that this > existing solution doesn't work and this draft tries to solve? Or, are there > some use cases that IKEv2 fails in detecting the existence of NAT? > I can understand the advantages of native ESP described in the draft: 1) > no keepalives or fewer keepalives, 2) no overhead of UDP header. Does this > draft target the use cases where IP + UDP + ESP and IP + ESP can both work > in the existence of NAT, and try to benefit from the native ESP? > > Regards & Thanks！ > Wei PAN (潘伟) > > > -Original Message- > > From: IPsec On Behalf Of Jen 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 > > > > -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! > > > > > > -- Forwarded message - > > From: > > Date: Fri, Mar 1, 2024 at 2:24 AM > > Subject: New Version Notification for > > draft-colitti-ipsecme-esp-ping-01.txt > > To: Jen Linkova , Lorenzo Colitti > > , Michael Richardson > > > > > > > > A new version of Internet-Draft draft-colitti-ipsecme-esp-ping-01.txt > > has been successfully submitted by Jen Linkova and posted to the IETF > > repository. > > > > Name: draft-colitti-ipsecme-esp-ping > > Revision: 01 > > Title:ESP Echo Protocol > > Date: 2024-02-29 > > Group:Individual Submission > > Pages:7 > > URL: > > > https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.txt > > Status: > > https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/ > > HTML: > > > https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.html > > HTMLized: > > https://datatracker.ietf.org/doc/html/draft-colitti-ipsecme-esp-ping > > Diff: > > > https://author-tools.ietf.org/iddiff?url2=draft-colitti-ipsecme-esp-ping- > > 01 > > > > Abstract: > > > >This document defines an ESP echo function which can be used to > >detect whether a given network path supports IPv6 ESP packets. > > > > > > > > The IETF Secretariat > > > > > > > > > > -- > > Cheers, Jen Linkova > > > > ___ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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* per-se.
> We prefer not to have to encapsulate.
Please forgive my ignorance of the scenarios. My understanding is that ESP
failure is usually because of the existence of NAT.
Do you mean ESP may not work even if there is no NAT between the two IPsec
peers?
If yes, I'd like to know more about how ESP failed and in what kind of
situations ESP will fail.
> I think that you are over-estimating the competency of some operators:
> the experience with IPv6 is often not there.
> Even when it is, not all equipment vendors are equally competent at
> implementing/documenting things.
Is this problem, i.e., IKE works but ESP doesn't work, only exist in the IPv6
network? Does IPv4 network have the same problem?
> Imagine a situation where IPsec will be used in a (sub)site to site
> configuration. For instance, between a billing system and an
> outsourced credit card processor. {Not replacing TLS, but in addition to}
> The administrators of the billing system request "IPsec" from their
> (inhouse) network operator, and the operator looks up their howto list,
> and enables UDP port 500 and 4500, because that's what IPv4 wanted.
> Now the billing system people wonder why the it seems to work, but in
> fact no traffic gets through. It can be very hard to debug.
I have two questions here.
First, what kind of reasons (except of NAT) will cause that no traffic gets
through?
Second, will UDP encapsulated ESP get through in these circumstances?
> The purpose of this protocol is to allow that debugging.
> The network operator people, who are not allowed into the billing
> system, can instead use an ESPping utility to send ESP traffic, adjusting
> their firewalls until they understand that UDP!=ESP.
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?
How does this draft help the adjustments and what kind of adjustments will be
performed?
> We also realized that one can write/modify traceroute to use ESPping
> to determine how far ESP actually gets.
This sounds useful.
Regards & Thanks！
Wei PAN (潘伟)
> There are also situations where there are ECMP routers in the way which
> simply do not know what to do with ESP. A network operator could
> introduce such a sytem into a previously working site-to-site VPN and
> suddenly things stop working, or get poor performance.
>
> --
> Michael Richardson , Sandelman Software
> Works
> -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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 about detecting NAT, it's about determining if ESP will work or not.
> supports the detection of NAT. After the detection of NAT, the peers
> can use IP + UDP (4500) + ESP to traverse the NAT. Are there some use
> cases that this existing solution doesn't work and this draft tries to
> solve? Or, are there some use cases that IKEv2 fails in detecting the
> existence of NAT?
It's not about detecting or avoiding *NAT* per-se.
We prefer not to have to encapsulate.
I think that you are over-estimating the competency of some operators: the
experience with IPv6 is often not there. Even when it is, not all equipment
vendors are equally competent at implementing/documenting things.
Imagine a situation where IPsec will be used in a (sub)site to site
configuration. For instance, between a billing system and an outsourced
credit card processor. {Not replacing TLS, but in addition to}
The administrators of the billing system request "IPsec" from their (inhouse)
network operator, and the operator looks up their howto list, and enables UDP
port 500 and 4500, because that's what IPv4 wanted.
Now the billing system people wonder why the it seems to work, but in fact no
traffic gets through. It can be very hard to debug.
The purpose of this protocol is to allow that debugging.
The network operator people, who are not allowed into the billing system, can
instead use an ESPping utility to send ESP traffic, adjusting their firewalls
until they understand that UDP!=ESP.
We also realized that one can write/modify traceroute to use ESPping to
determine how far ESP actually gets.
There are also situations where there are ECMP routers in the way which
simply do not know what to do with ESP. A network operator could introduce
such a sytem into a previously working site-to-site VPN and suddenly things
stop working, or get poor performance.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt
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 slides, is because of NAT. IKEv2 already supports the
detection of NAT. After the detection of NAT, the peers can use IP + UDP (4500)
+ ESP to traverse the NAT. Are there some use cases that this existing solution
doesn't work and this draft tries to solve? Or, are there some use cases that
IKEv2 fails in detecting the existence of NAT?
I can understand the advantages of native ESP described in the draft: 1) no
keepalives or fewer keepalives, 2) no overhead of UDP header. Does this draft
target the use cases where IP + UDP + ESP and IP + ESP can both work in the
existence of NAT, and try to benefit from the native ESP?
Regards & Thanks！
Wei PAN (潘伟)
> -Original Message-
> From: IPsec On Behalf Of Jen 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
>
> -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!
>
>
> -- Forwarded message -
> From:
> Date: Fri, Mar 1, 2024 at 2:24 AM
> Subject: New Version Notification for
> draft-colitti-ipsecme-esp-ping-01.txt
> To: Jen Linkova , Lorenzo Colitti
> , Michael Richardson
>
>
>
> A new version of Internet-Draft draft-colitti-ipsecme-esp-ping-01.txt
> has been successfully submitted by Jen Linkova and posted to the IETF
> repository.
>
> Name: draft-colitti-ipsecme-esp-ping
> Revision: 01
> Title:ESP Echo Protocol
> Date: 2024-02-29
> Group:Individual Submission
> Pages:7
> URL:
> https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/
> HTML:
> https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-colitti-ipsecme-esp-ping
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-colitti-ipsecme-esp-ping-
> 01
>
> Abstract:
>
>This document defines an ESP echo function which can be used to
>detect whether a given network path supports IPv6 ESP packets.
>
>
>
> The IETF Secretariat
>
>
>
>
> --
> Cheers, Jen Linkova
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
[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, so ESP packets with SPI == 7 or 8 and next header==59 are not considered to be dummy packets. Comments are appreciated! -- Forwarded message - From: Date: Fri, Mar 1, 2024 at 2:24 AM Subject: New Version Notification for draft-colitti-ipsecme-esp-ping-01.txt To: Jen Linkova , Lorenzo Colitti , Michael Richardson A new version of Internet-Draft draft-colitti-ipsecme-esp-ping-01.txt has been successfully submitted by Jen Linkova and posted to the IETF repository. Name: draft-colitti-ipsecme-esp-ping Revision: 01 Title:ESP Echo Protocol Date: 2024-02-29 Group:Individual Submission Pages:7 URL: https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.txt Status: https://datatracker.ietf.org/doc/draft-colitti-ipsecme-esp-ping/ HTML: https://www.ietf.org/archive/id/draft-colitti-ipsecme-esp-ping-01.html HTMLized: https://datatracker.ietf.org/doc/html/draft-colitti-ipsecme-esp-ping Diff: https://author-tools.ietf.org/iddiff?url2=draft-colitti-ipsecme-esp-ping-01 Abstract: This document defines an ESP echo function which can be used to detect whether a given network path supports IPv6 ESP packets. The IETF Secretariat -- Cheers, Jen Linkova ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
