Paul Wouters <p...@nohats.ca> wrote:
>> For a basic use case, any response would suffice. The essential
>> requirement is the ability to send a request and receive a response
>> from the IPsec peer, which is why I proposed the minimal solution to
>> begin with.
> I disagree. VPN protocols are actively attacked by network operators in
> oppressive regimes. These regimes often will cause odd failures that
> ensures the enduser keeps trying because if somewhat/sometimes works,
> which stops those users from trying another protocol that the operator
> cannot block yet.
> I could see how those network operators would reply to these probes,
> but still mess or block the real traffic.
> I think the signal of "this network can transport this ESP" should come
> from the endpoints and not be falsifiable.
1) I'm in favour of supporting this stronger assertion of communication.
But, it requires that IKE be up, working, and able to negotiate.
Sometimes that's just too much to figure out when working with
unsophisticated end-users and/or administrators.
2) I still think that the reserved SPI concept is worth standardizing,
because sometimes it's just really basic debugging one needs.
Being able to puzzle through a series of nodes where one is screwing with
ESP, and being able to "up-arrow-return" to try again is a good feature.
--
Michael Richardson <mcr+i...@sandelman.ca>, 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
