[IPsec] Re: Comments on draft-pwouters-ipsecme-delete-info

[Paul Wouters <[e-mail]>]

On Wed, Jul 31, 2024 at 3:32 AM Valery Smyslov <[e-mail]>
wrote:

> Hi Paul,
>
>
>
> (I think gmail is reaching its limits on careful quoting context, hope I
> get it all right)
>
>
>
>          I will mark my replies with this color.
>

Thanks, that was very helpful!


>
>          Will it help your debugging? I doubt.
>
>
>
> No but if it says "abra cadabra conn 'vpn-customer1-toronto-rain[4]' more
> words and words", it could already help me
>
> debugging so I know to look for my connection named
> vpn-customer1-toronto-rain, using state object 4. Obviously,
>
> this depends on implementation. But it is definitely not useless.
>
>
>
>          And what you will do with “vpn-customer1-toronto-rain[4]” at
> your side? This is the name of the connection
>
>          on peer’s side that doesn’t relate to your configuration at all
> (even more true for state object). You still
>
>          to have to call the peer and in this case the only information it
> needs is an SPI.
>

In a way, it would be like getting a selection of the peer's logging
without needing to ask the customer to ask the vendor
on how to get logging. I agree the usefulness would be depending on the
implementations and my knowledge. Logging
a SPI can be helpful, although the notify is already received under a known
IKE SPI, which is why I had not added it
as payload to the notify data, and the delete payload itself has the IPsec
SPI already.


>
>          By the way, I think that it would be more helpful to the user if
> you include “Related SPI” field
>
>          in your notify – the SPI of the SA that caused the deletion of
> this SA.
>
>          In case of INITIAL_CONTACT this might help.
>

It could be useful, but is it useful enough to add it to the structure so
every "reason" has to have a "related SPI"
field? It might be, andwould be more structural that expecting it in a
"free from field". So I wouldn't object to
adding this.

  2. The list of reasons looks to me both incomplete and excessive at the
> same
> time.
>     For example, CONFIGURATION_CHILD_REMOVED and CONFIGURATION_IKE_REMOVED
>     are not needed, since you either delete IKE SA or Child SA in a single
> exchange, so it is
>     always clear what configuration is removed and only one such reason
> would suffice.
>
>
>
> This is not about the current instance of the exchange but about the local
> configuration. It basically
>
> says "this one tunnel is no longer configured" vs "the entire config for
> the peer has been removed".
>
>
>
>          OK, this is not clear from the draft (that increases my concerns
> that without
>
>          direct (phone) contact with the peer these reason have little
> value).
>
>
>
> Yes, the notify reason basically TOLD YOU, there is an expectation
> difference between you and the peer. Maybe
>
> you forgot to pay a bill. It's a feature not a bug :)
>
>
>
>          And the bill number with the needed sum will be included into
> the reason text? J
>

No, you would do that on the next connection attempt, or else you have to
implement this twice :)


>
>
>
>
>          Can you please provide an example or give more detailed
> explanation how this can happen?
>
>          From my understanding of IKEv2 it is always known from the local
> logs
>
>          which SA is deleted as erroneous in case of simultaneous rekey.
> Am I missing something?
>
>
>
> Often when we deal with customers, they cannot produce a log on their end
> and finding reasons about their
>
> behaviour is impossible. Having the remote peer put some information into
> a delete reason payload would mean
>
> the customer's equipment does tell us a bit better why, without needing
> the remote logs.
>
>
>
>          My point was that deletion due to the simultaneous rekey is
> always clear from any side’s logs…
>
>          At least from our experience. The only case when remote logs are
> needed in this case is
>
>          when you turned off local logging…
>

We do have customers running with no logging, and even with "IP address
masking", but I think this use case would
be rare and not the main purpose of the draft.


> The point of this reason is to put the Exec Summary of that phone call in
> the payload :)
>
>
>
>          This is not really needed. The only information that is needed
> for the phone call is SPI of the SA.
>
>
>
> Not in my world. The extend of info a customer tells me about their Cisco
> failure is usually a "tunnel failed".
>
> They usually dont know how to get logs, how to enable debugging, or who to
> talk to to help with their ipsec
>
> machine.
>
>
>
>          In this case how the reason notify would help? I presumed that
> this notify is for logging purposes only
>
>          and if users don’t know how to get their own logs, then they
> cannot tell you the received reason.
>
>          Or is it intended to be displayed to the user on a UI? Randomly
> popping up?
>

We can usually tell our customers to get us libreswan logs, but not peer
logs. If the peers send back some more
information "automatically", this can help administrators. Note the use
cases I am mostly concerned about are
site-to-site type deployments and not "remote access VPN for $10/month"
retail deployments.


>           I see. It won’t help those poor who was down when the hardware
> started been replaced –
>
>          they never receive this announcement and won’t know why the
> cannot connect J
>
>
>
> Some of my customers run an RFC5685 IKEV2 redirect proxy in front of their
> servers, so this wouldn't be
>
> a problem :)   So imagine you receive a "deleted connection because IPsec
> GW being upgraded", but with
>
> 0 downtime. You redirect and the proxy redirects you. If you were down for
> a few seconds, you know what the
>
> cause was, that you not need to do anything.
>
>
>
>          Redirect would help in this case regardless of the reason code.
>
>          As a customer, I’d rather use it immediately if I need an access,
> rather than
>
>          waiting the time indicated in the reason (because it is only a
> hint J).
>

Yes of course you would automatically use the other endpoint. But now you
have your own end retrying and
failing and you don't know why. But if you look back in the logs you find
out why one of your redundant endpoints
went away,

Paul