Michael Richardson <mcr+i...@sandelman.ca> 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
