(I think gmail is reaching its limits on careful quoting context, hope I get it all right)
On Tue, Jul 30, 2024 at 10:49 AM Valery Smyslov <smyslov.i...@gmail.com> wrote: > Hi Paul, > > > > On Mon, Jul 29, 2024 at 6:18 AM Valery Smyslov <smyslov.i...@gmail.com> > wrote: > > Hi, > > I have some comments on draft-pwouters-ipsecme-delete-info that I tried to > express at IETF120, > but due to lack of time they were not responded to. > > 1. I'm very much concerned with the "Delete Reason Text" field. My primary > question - > in what language this free text explanation is supposed to be? I > suppose > > it is assumed to be English, but why do you think all customers in the > world understand English well enough > for this field to be really useful? If arbitrary language is allowed, > then we need to add a language tag, > otherwise it is generally impossible to even recognize what language > the > text is in. > And allowing arbitrary language makes this field even less useful. > > > > The idea is that the provider uses some language it knows the receiver > would understand, in addition > > to the enum. Computers and UIs can be use the ENUM, and I expect most > people would not need > > or want custom text. However, when presented at IETF119 the group was > split. Half wanted an enum > > and half wanted free flow text. This was the compromise. > > > > > In general, I think it is a bad idea to transmit text strings to be > read > by users in a low level > protocol which IKEv2 is. This is an UI issue, and it is the UI that > should properly display to the user in a user > chosen language what is happening. > > > > In general, I agree. Although I could also see the freeform text to > perhaps but in some more details > > that could make debugging easier. > > > > 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. > 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 :) > > > SIMULTANEOUS_REKEY adds no new information, > since you always understand this reason from local logs. On the other > hand, > it is not specified what to indicate in the reason when ESP SA is being > deleted > in response to deleting the tied ESP SA for the other direction. > > > > In general yes, but again we have seen race conditions and uncertainly, > where I think it would have > > helped debugging if this reason was explicitly logged as part of the > exchange. > > > > 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. In general, I think that indicating the reason the SA is deleted doesn't > help much the user much. > In many cases it can be inferred from local logs. And if it cannot, > then > you probably > will to contact the other end in any case to get more detailed > information on the reason, > in which case sending the reason on the wire has little value. > > > > 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. And perhaps entities that don't answer the phone (eg hyperscale cloud > providers) would > > populate those automatically, since they are usually not reachable by > phone :) > > > > Yes, but what you do with the reason information in this case? > > Either the deletion is expected (you may guess the reason or > knows it for sure) or not. > > In the latter case, when the peer behaves strangely to you > (suddenly deletes SA with no clear reason) > > you either live with this or still have to reach out to the peer > by phone. > > Even if peer sends you CONFIGURATION_IKE_REMOVED won’t > > you try to phone and ask “What the hell?! Why did you deny my > access?” > > > > If you don't think it is useful, by all means don't send it and ignore it > when received. > > Some of my customers have explicitly asked for this, so there is a need > (unreasonable or not :) > > > > I see your. Customers sometimes have very strange (and creative L) > ideas. > > But then please change the intended status to Informational (the > draft now is Proposed Standard), > > so that I have my conscience clear when choose not to implement > it J > I have no issue making this Informational or Experimental. 3. Perhaps the most useful field is Downtime. But thinking more about this, > I believe that since this value is only a hint, you will probably not > trust it. > For example, if you have to communicate to the peer ASAP and it deletes > SA indicating that downtime is 1 hour, you will not wait for all this > time, > you will try to establish new SA every minute (it costs you nothing, but > you have a chance to get it up earlier). > > > > It is not about trust, it is all about hints. If this field says "60" and > the enum says REBOOT, you > > might just wait a minute or just let the system retry as it. If it says > "3600" with OTHER with "replacing > > broken hardware", you might decide you want to redirect the tunnel to a > fallback solution. > > > > 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. Paul
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
