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.
As I wrote in the message to Chris, if we use any human-readable text
in the protocol,
then we MUST support multiple languages to be compliant with BCP18
(RFC2277, Sections 4.4, 4.2).
This is what “Typical ART Area Issues” page
(https://wiki.ietf.org/group/art/TypicalARTAreaIssues)
requires to check when doing ART review. I really don’t want to open this I18N
can of worms L
And in this case the text won’t always help much. Will you understand
what is happening if I send you:
Сервер отключен для пусконаладочных работ, включим после дождичка в четверг
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.
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.
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
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…
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?
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).
Regards,
Valery.
Paul
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
