Subject: [Ecrit] planned-changes: two questions

From: "Randall Gellens" <[email-masked]>
Date: Fri, 27 Aug 2021 14:41:09 -0700

I think we're moving to a model where:
- In a query, a client can request to be notified when the location 
should be revalidated;
- In the response, the server provides an ID which the client associates 
with the location it just validated;
- The server sends a notification to the URI, containing the ID;
- The client revalidates each location with which that ID is associated.

Question 1: Does the server delete/inactivate the URI once it has sent 
the notification?

Question 2: Presumably, when the client revalidates the location(s), it 
will again request notification.  Does the server return the same ID as 
before, or a different ID?  A different ID could perhaps be useful in 
edge cases where the server didn't send or the client didn't get the 
notification, but any utility seems small.  If it's the same ID, then 
the answer to question 1 can be that the URI remains active until the 
client asks to no longer be notified (by sending an empty URI?).

--Randall

---

From: "Caron, Guy" <[email-masked]>
Date: Mon, 30 Aug 2021 15:08:00 +0000

My thoughts Inline below.

Guy

-----Message d'origine-----
De : Ecrit <[email-masked]> De la part de Randall Gellens
Envoyé : 27 août 2021 17:41
À : ECRIT <[email-masked]>
Objet : [EXT][Ecrit] planned-changes: two questions

I think we're moving to a model where:
- In a query, a client can request to be notified when the location should be revalidated;
- In the response, the server provides an ID which the client associates with the location it just validated;
- The server sends a notification to the URI, containing the ID;
- The client revalidates each location with which that ID is associated.

Question 1: Does the server delete/inactivate the URI once it has sent the notification?
[GC] The URI is now a static one that is specific to a Client (rather than a location stored by the Client). I think it should remain active until the Client sends a new one (for whatever reason).

Question 2: Presumably, when the client revalidates the location(s), it will again request notification.
[GC] Yes, by providing <plannedChanges> with the same generic URI or a new one (for whatever reason).

  Does the server return the same ID as before, or a different ID?
[GC] It would be the same ID since it is associated with a location (defined by policy at the Server) unless the "location" has changed (the location itself or the policy defining it). An example of such change is when the underlying data structure for a set of locations has changed, such as address points being added on top of road centerline data. 

  A different ID could perhaps be useful in edge cases where the server didn't send or the client didn't get the notification, but any utility seems small.  If it's the same ID, then the answer to question 1 can be that the URI remains active until the client asks to no longer be notified (by sending an empty URI?).
[GC] You bring a good point about the Client asking to no longer be notified. I think this needs to be supported although I don't see why a Client supporting planned-changes would want to stop using it. Do we do so by providing an empty <plannedChanges>  or by not providing <plannedChanges> at all? In either case, we need some text on the Client and Server behaviours.

--Randall

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit
------------------------------------------------------------------------------
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: Brian Rosen <[email-masked]>
Date: Mon, 30 Aug 2021 11:22:14 -0400

Answer 1: yes.  Since there is going to be a revalidation, just deleting the setting seems right to me.
Answer 2: Up to server.  If I were implementing, I would hash the real ID with the URI and some kind of predictable nonce.  

We probably have to say more about how the server identifies the client, so that replacement of the URI works.  Could we say we use the domain of the URI (the entire domain with all the dots) to identify the client, and anything can occur after it (meaning a slash and whatever)?  If we do that, then how would delete the notification?  Force there to be something other than the domain (ugly).  Explicit delete request?

Hmmm, we’ve opened a DoS attack: a rogue client stores a bunch of URIs for servers it wants to victimize.  In North America we have a real simple solution for that, because we have a PKI, so we know, for sure, who the client is, and could restrict who we allow to store URIs, but that wouldn’t be true in general.  Also, it would be nice for the client to have confidence the mechanism worked before it needed it.

So
Let’s add a “command” to plannedChange in the findService request.  And, have the client have a response to the notification which is the ID (json with the 200)

The client starts by sending a command of “initialize”.  The domain is the identity of the client.  The response is an immediate notification to the with whatever LI was in the request and an ID.  The  response by the client (which is the notification web server) is a piece of json containing the ID.  We can say that the LI in this initialize command could be something simple like the Country Code that wouldn’t get a planned change.

Thereafter, the LoST server (notification client) periodically repeats this keepalive notification every day or week with the initialize LI.  The client has to respond with the ID.

The regular notification request is a command of “notify”.  The server ignores a request for notification from an uninitialized client.
The notification can be deleted with a command of “delete”.  If you delete the initialize LI, then the server won’t send any more notifications to that client and deletes all URIs it was saving for that client.  The client would have to re-initialize to reset.

Brian

> On Aug 27, 2021, at 5:41 PM, Randall Gellens <[email-masked]> wrote:
> 
> Question 2: Presumably, when the client revalidates the location(s), it will again request notification.  Does the server return the same ID as before, or a different ID?  A different ID could perhaps be useful in edge cases where the server didn't send or the client didn't get the notification, but any utility seems small.  If it's the same ID, then the answer to question 1 can be that the URI remains active until the client asks to no longer be notified (by sending an empty URI?).
> 
> --Randall
>

---

From: "Randall Gellens" <[email-masked]>
Date: Mon, 30 Aug 2021 14:51:52 -0700

Works for me, but the draft should be updated to say this (once a server 
successfully sends a notification, it deletes the URI, and the ID 
returned is entirely up to the server and might or might not be 
different on a subsequent request for the same location).

--Randall

On 30 Aug 2021, at 8:22, Brian Rosen wrote:

> Answer 2: Up to server.  If I were implementing, I would hash the real 
> ID with the URI and some kind of predictable nonce.
>
> We probably have to say more about how the server identifies the 
> client, so that replacement of the URI works.  Could we say we use the 
> domain of the URI (the entire domain with all the dots) to identify 
> the client, and anything can occur after it (meaning a slash and 
> whatever)?  If we do that, then how would delete the notification?  
> Force there to be something other than the domain (ugly).  Explicit 
> delete request?
>
> Hmmm, we’ve opened a DoS attack: a rogue client stores a bunch of 
> URIs for servers it wants to victimize.  In North America we have a 
> real simple solution for that, because we have a PKI, so we know, for 
> sure, who the client is, and could restrict who we allow to store 
> URIs, but that wouldn’t be true in general.  Also, it would be nice 
> for the client to have confidence the mechanism worked before it 
> needed it.
>
> So
> Let’s add a “command” to plannedChange in the findService 
> request.  And, have the client have a response to the notification 
> which is the ID (json with the 200)
>
>
> The client starts by sending a command of “initialize”.  The 
> domain is the identity of the client.  The response is an immediate 
> notification to the with whatever LI was in the request and an ID.  
> The  response by the client (which is the notification web server) is 
> a piece of json containing the ID.  We can say that the LI in this 
> initialize command could be something simple like the Country Code 
> that wouldn’t get a planned change.
>
> Thereafter, the LoST server (notification client) periodically repeats 
> this keepalive notification every day or week with the initialize LI.  
> The client has to respond with the ID.
>
> The regular notification request is a command of “notify”.  The 
> server ignores a request for notification from an uninitialized 
> client.
> The notification can be deleted with a command of “delete”.  If 
> you delete the initialize LI, then the server won’t send any more 
> notifications to that client and deletes all URIs it was saving for 
> that client.  The client would have to re-initialize to reset.
>
> Brian
>
>> - In the response, the server provides an ID which the client 
>> associates with the location it just validated;
>> Question 2: Presumably, when the client revalidates the location(s), 
>> it will again request notification.  Does the server return the same 
>> ID as before, or a different ID?  A different ID could perhaps be 
>> useful in edge cases where the server didn't send or the client 
>> didn't get the notification, but any utility seems small.  If it's 
>> the same ID, then the answer to question 1 can be that the URI 
>> remains active until the client asks to no longer be notified (by 
>> sending an empty URI?).
>>
>> --Randall
>>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 30 Aug 2021 17:57:34 -0400

Yes, I agree.

Brian

---

From: "Caron, Guy" <[email-masked]>
Date: Tue, 31 Aug 2021 11:37:52 +0000

Well, this is not going in the direction I thought.

What is the purpose of deleting the URIs at the Server post-validation?

Regarding opening a new DoS, I guess I'm not following. Wouldn't this case be covered by the security considerations in RFC 5222?

What you're proposing puts back significant load on the Servers (a key consideration for creating planned-changes in the first place) and complicates the mechanism.

Guy

-----Message d'origine-----
De : Ecrit <[email-masked]> De la part de Brian Rosen
Envoyé : 30 août 2021 11:22
À : Randall Gellens <[email-masked]>
Cc : ECRIT <[email-masked]>
Objet : [EXT]Re: [Ecrit] planned-changes: two questions

So

Brian

---

From: Brian Rosen <[email-masked]>
Date: Tue, 31 Aug 2021 08:10:33 -0400

You delete the URI when you delete the record in the LIS.

I don’t think this is covered in 5222.  The mechanism causes the LoST server to send notifications to the client, but the client is allowed to put any URI in the record, and it can add it to as many records as it wants.  An evil implementation could record URIs against multiple targets that were unaware that the evil implementation did it, until they got a large number of PUSH transactions they didn’t expect or understand as a result of a large planned change.

The proposed mechanism qualifies the client URI before its used in a planned change.

Brian

> On Aug 31, 2021, at 7:37 AM, Caron, Guy <[email-masked]> wrote:
>

---

From: "Caron, Guy" <[email-masked]>
Date: Tue, 31 Aug 2021 13:01:48 +0000

Inline.

Guy

-----Message d'origine-----
De : Brian Rosen <[email-masked]> 
Envoyé : 31 août 2021 08:11
À : Caron, Guy <[email-masked]>
Cc : Randall Gellens <[email-masked]>; ECRIT <[email-masked]>
Objet : [EXT]Re: [Ecrit] planned-changes: two questions

You delete the URI when you delete the record in the LIS.
[GC] That's fine but that was not the question Randall posed. He asked whether the URI is deleted after a notification. I agree that if the Client does not host the location anymore that the URI associated with that location in the Server should be deleted. This could be achieved with an empty <plannedChange>.

I don’t think this is covered in 5222.  The mechanism causes the LoST server to send notifications to the client, but the client is allowed to put any URI in the record, and it can add it to as many records as it wants.
[GC] I thought we agreed on using one generic URI per Client. Clients should be authenticated by the Servers.
  An evil implementation could record URIs against multiple targets that were unaware that the evil implementation did it, until they got a large number of PUSH transactions they didn’t expect or understand as a result of a large planned change.
[GC] Only authenticated Clients should be allowed to provide URIs to be stored by the Servers.

Brian

> De : Ecrit <[email-masked]> De la part de Brian Rosen Envoyé : 
> 30 août 2021 11:22 À : Randall Gellens <[email-masked]> Cc 
> : ECRIT <[email-masked]> Objet : [EXT]Re: [Ecrit] planned-changes: two 
> questions
> 
> Let’s add a “command” to plannedChange in the findService request.  
> And, have the client have a response to the notification which is the 
> ID (json with the 200)
> 
> 
> ----------------------------------------------------------------------
> -------- External Email: Please use caution when opening links and 
> attachments / Courriel externe: Soyez prudent avec les liens et 
> documents joints

---

From: Brian Rosen <[email-masked]>
Date: Tue, 31 Aug 2021 13:27:32 -0400

If the work group wants to have the LoST server keep the URI until expressly deleted, that’s okay with me.

Authenticating the client to the server doesn’t mean the URI is authenticated.  We can’t restrict the URI to be the same entity as the client running the LoST transaction.  And the clients are wide ranging.  Could be an enterprise running its own LIS for example.  We can’t assume the North American PKI is workable everywhere, and even that doesn’t extend to an enterprise LIS.  ISTM we have to run a test transaction with the notification service to make sure it’s what we think it is.

Brian

> On Aug 31, 2021, at 9:01 AM, Caron, Guy <[email-masked]> wrote:
> 
> Inline.
> 
> Guy
> 
> De : Brian Rosen <[email-masked] <mailto:[email-masked]>> 
> À : Caron, Guy <[email-masked] <mailto:[email-masked]>>
> Cc : Randall Gellens <[email-masked] <mailto:[email-masked]>>; ECRIT <[email-masked] <mailto:[email-masked]>>

---

From: "Randall Gellens" <[email-masked]>
Date: Tue, 31 Aug 2021 10:35:33 -0700

If a malicious client registers a URI that is designed to attack a third 
site, the test transaction causes the LoST server to connect to it and 
POST a command.  Without a test transaction, the LoST server stores the 
URI and at a future time connects to it and sends a command.  Either 
way, a LoST client can register potentially one URI per queried 
location, and a LoST server will connect to that URI and POST a message. 
  A queried location could be tied to many other locations, so there 
could be many locations for which a change would trigger the LoST server 
to use the URI, but is that worse?

--Randall

On 31 Aug 2021, at 10:27, Brian Rosen wrote:

> Authenticating the client to the server doesn’t mean the URI is 
> authenticated.  We can’t restrict the URI to be the same entity as 
> the client running the LoST transaction.  And the clients are wide 
> ranging.  Could be an enterprise running its own LIS for example.  We 
> can’t assume the North American PKI is workable everywhere, and even 
> that doesn’t extend to an enterprise LIS.  ISTM we have to run a 
> test transaction with the notification service to make sure it’s 
> what we think it is.
>
> Brian
>
>
>
>> Cc : Randall Gellens <[email-masked] 
>> <mailto:[email-masked]>>; ECRIT <[email-masked] 
>> <mailto:[email-masked]>>
>> [GC] That's fine but that was not the question Randall posed. He 
>> asked whether the URI is deleted after a notification. I agree that 
>> if the Client does not host the location anymore that the URI 
>> associated with that location in the Server should be deleted. This 
>> could be achieved with an empty <plannedChange>.
>>
>> I don’t think this is covered in 5222.  The mechanism causes the 
>> LoST server to send notifications to the client, but the client is 
>> allowed to put any URI in the record, and it can add it to as many 
>> records as it wants.
>>  An evil implementation could record URIs against multiple targets 
>> that were unaware that the evil implementation did it, until they got 
>> a large number of PUSH transactions they didn’t expect or 
>> understand as a result of a large planned change.
>>> Regarding opening a new DoS, I guess I'm not following. Wouldn't 
>>> this case be covered by the security considerations in RFC 5222?
>>>
>>> What you're proposing puts back significant load on the Servers (a 
>>> key consideration for creating planned-changes in the first place) 
>>> and complicates the mechanism.
>>>
>>> Guy
>>>
>>>
>>> Envoyé :
>>> Answer 2: Up to server.  If I were implementing, I would hash the 
>>> real ID with the URI and some kind of predictable nonce.
>>>
>>> client, so that replacement of the URI works.  Could we say we use 
>>> the domain of the URI (the entire domain with all the dots) to 
>>> identify the client, and anything can occur after it (meaning a 
>>> slash and whatever)?  If we do that, then how would delete the 
>>> notification?  Force there to be something other than the domain 
>>> (ugly).  Explicit delete request?
>>>
>>> real simple solution for that, because we have a PKI, so we know, 
>>> for sure, who the client is, and could restrict who we allow to 
>>> store URIs, but that wouldn’t be true in general.  Also, it would 
>>> be nice for the client to have confidence the mechanism worked 
>>> before it needed it.
>>>
>>> So
>>> request.
>>> The  response by the client (which is the notification web server) 
>>> is a piece of json containing the ID.  We can say that the LI in 
>>> this initialize command could be something simple like the Country 
>>> Code that wouldn’t get a planned change.
>>>
>>> Thereafter, the LoST server (notification client) periodically 
>>> repeats this keepalive notification every day or week with the 
>>> initialize LI.  The client has to respond with the ID.
>>>
>>>> Question 2: Presumably, when the client revalidates the 
>>>> location(s), it will again request notification.  Does the server 
>>>> return the same ID as before, or a different ID?  A different ID 
>>>> could perhaps be useful in edge cases where the server didn't send 
>>>> or the client didn't get the notification, but any utility seems 
>>>> small.  If it's the same ID, then the answer to question 1 can be 
>>>> that the URI remains active until the client asks to no longer be 
>>>> notified (by sending an empty URI?).
>>>>
>>>> --Randall
>>>>
>> External Email: Please use caution when opening links and attachments 
>> / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: Brian Rosen <[email-masked]>
Date: Tue, 31 Aug 2021 13:53:37 -0400

Of course an attacker would conceal itself and register multiple URIs under different identities.  But the bigger  problem is that if a large planned change occurred, the victim could receive a large number of notifications it didn’t expect.

With a test transition, we know that the client expects to see notifications, we only need one per URI (we could specify one per domain — after the scheme and before the first slash).  If we don’t get the ID, we know not to allow that URI to be provisioned.  So it’s one test transaction vs a large number of planned change transactions.

Brian

> On Aug 31, 2021, at 1:35 PM, Randall Gellens <[email-masked]> wrote:
> 
> If a malicious client registers a URI that is designed to attack a third site, the test transaction causes the LoST server to connect to it and POST a command. Without a test transaction, the LoST server stores the URI and at a future time connects to it and sends a command. Either way, a LoST client can register potentially one URI per queried location, and a LoST server will connect to that URI and POST a message. A queried location could be tied to many other locations, so there could be many locations for which a change would trigger the LoST server to use the URI, but is that worse?
> 
> --Randall
> 
>> On Aug 31, 2021, at 9:01 AM, Caron, Guy <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Inline.
>> 
>> Guy
>> 
>>> On Aug 31, 2021, at 7:37 AM, Caron, Guy <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> De : Ecrit <[email-masked] <mailto:[email-masked]>> De la part de Brian Rosen Envoyé : 
>>> 30 août 2021 11:22 À : Randall Gellens <[email-masked] <mailto:[email-masked]>> Cc 
>>> : ECRIT <[email-masked] <mailto:[email-masked]>> Objet : [EXT]Re: [Ecrit] planned-changes: two 
>>> questions
>>> 
>>>> On Aug 27, 2021, at 5:41 PM, Randall Gellens <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>

---

From: "Randall Gellens" <[email-masked]>
Date: Tue, 31 Aug 2021 11:56:12 -0700

i understand that the concern is allowing a client to leverage the LoST 
server to attack a large number of targets, I'm just not clear 
mechanically how such leverage potentially works.  Each validation query 
can store a URI, and that URI may get associated with a large number of 
locations.  Maybe there's a street name change or an annexation.  So 
maybe thousands or tens or hundreds of thousands of locations are 
potentially invalidated.  They all have the same URI associated with 
them, so the LoST server connects to the URI once and POSTs one 
notification, no?

--Randall

On 31 Aug 2021, at 10:53, Brian Rosen wrote:

> Of course an attacker would conceal itself and register multiple URIs 
> under different identities.  But the bigger  problem is that if a 
> large planned change occurred, the victim could receive a large number 
> of notifications it didn’t expect.
>
> With a test transition, we know that the client expects to see 
> notifications, we only need one per URI (we could specify one per 
> domain — after the scheme and before the first slash).  If we 
> don’t get the ID, we know not to allow that URI to be provisioned.  
> So it’s one test transaction vs a large number of planned change 
> transactions.
>
> Brian
>
>
>> If a malicious client registers a URI that is designed to attack a 
>> third site, the test transaction causes the LoST server to connect to 
>> it and POST a command. Without a test transaction, the LoST server 
>> stores the URI and at a future time connects to it and sends a 
>> command. Either way, a LoST client can register potentially one URI 
>> per queried location, and a LoST server will connect to that URI and 
>> POST a message. A queried location could be tied to many other 
>> locations, so there could be many locations for which a change would 
>> trigger the LoST server to use the URI, but is that worse?
>>
>> --Randall
>>
>> can’t assume the North American PKI is workable everywhere, and 
>> even that doesn’t extend to an enterprise LIS.  ISTM we have to run 
>> a test transaction with the notification service to make sure it’s 
>> what we think it is.
>>
>> Brian
>>
>>
>>
>>> [GC] I thought we agreed on using one generic URI per Client. 
>>> Clients should be authenticated by the Servers.
>>> that were unaware that the evil implementation did it, until they 
>>> got a large number of PUSH transactions they didn’t expect or 
>>>>> On Aug 27, 2021, at 5:41 PM, Randall Gellens 
>>>>> <[email-masked] <mailto:[email-masked]>> 
>>>>> wrote:
>>>>>
>>> External Email: Please use caution when opening links and

---

From: Brian Rosen <[email-masked]>
Date: Tue, 31 Aug 2021 15:34:56 -0400

No.  

There is one URI, but many IDs, one per unique record at the LoST server that is involved in a planned change.  The one URI will receive one notification per ID it has registered for.

> On Aug 31, 2021, at 2:56 PM, Randall Gellens <[email-masked]> wrote:
> 
> i understand that the concern is allowing a client to leverage the LoST server to attack a large number of targets, I'm just not clear mechanically how such leverage potentially works. Each validation query can store a URI, and that URI may get associated with a large number of locations. Maybe there's a street name change or an annexation. So maybe thousands or tens or hundreds of thousands of locations are potentially invalidated. They all have the same URI associated with them, so the LoST server connects to the URI once and POSTs one notification, no?
> 
> --Randall
> 
>> On Aug 31, 2021, at 1:35 PM, Randall Gellens <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>>> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>
>>>> 
>>>> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>

---

From: "Caron, Guy" <[email-masked]>
Date: Tue, 31 Aug 2021 20:38:39 +0000

If we make <revalidateLocation> a list of IDs, one notification per URI per planned change would be sufficient.

Guy

De : Brian Rosen <[email-masked]>
Envoyé : 31 août 2021 15:35
À : Randall Gellens <[email-masked]>
Cc : Caron, Guy <[email-masked]>; ECRIT <[email-masked]>
Objet : [EXT]Re: [Ecrit] planned-changes: two questions

No.

On Aug 31, 2021, at 2:56 PM, Randall Gellens <[email-masked]<mailto:[email-masked]>> wrote:

Brian

On Aug 31, 2021, at 1:35 PM, Randall Gellens <[email-masked]<mailto:[email-masked]>> wrote:

Brian

On Aug 31, 2021, at 9:01 AM, Caron, Guy <[email-masked]<mailto:[email-masked]>> wrote:

Inline.

Guy

-----Message d'origine-----
De : Brian Rosen <[email-masked]<mailto:[email-masked]>>
Envoyé : 31 août 2021 08:11
À : Caron, Guy <[email-masked]<mailto:[email-masked]>>
Cc : Randall Gellens <[email-masked]<mailto:[email-masked]>>; ECRIT <[email-masked]<mailto:[email-masked]>>
Objet : [EXT]Re: [Ecrit] planned-changes: two questions

Brian

On Aug 31, 2021, at 7:37 AM, Caron, Guy <[email-masked]<mailto:[email-masked]>> wrote:

Guy

-----Message d'origine-----
De : Ecrit <[email-masked]<mailto:[email-masked]>> De la part de Brian Rosen Envoyé :
30 août 2021 11:22 À : Randall Gellens <[email-masked]<mailto:[email-masked]>> Cc
: ECRIT <[email-masked]<mailto:[email-masked]>> Objet : [EXT]Re: [Ecrit] planned-changes: two
questions

So

Brian

On Aug 27, 2021, at 5:41 PM, Randall Gellens <[email-masked]<mailto:[email-masked]>> wrote:

--Randall

_______________________________________________
Ecrit mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ecrit

[email-masked]<mailto:[email-masked]>

________________________________
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints

---

From: Brian Rosen <[email-masked]>
Date: Tue, 31 Aug 2021 16:55:03 -0400

If we did that, we would have to implement limit and start to handle a large list.  

Brian

> On Aug 31, 2021, at 4:38 PM, Caron, Guy <[email-masked]> wrote:
> 
> On Aug 31, 2021, at 2:56 PM, Randall Gellens <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Caron, Guy" <[email-masked]>
Date: Tue, 31 Aug 2021 20:57:17 +0000

The size of the list could be a policy at the Server.

Guy

Envoyé : 31 août 2021 16:55

Brian

On Aug 31, 2021, at 4:38 PM, Caron, Guy <[email-masked]<mailto:[email-masked]>> wrote:

Guy

De : Brian Rosen <[email-masked]<mailto:[email-masked]>>
Envoyé : 31 août 2021 15:35
À : Randall Gellens <[email-masked]<mailto:[email-masked]>>
Cc : Caron, Guy <[email-masked]<mailto:[email-masked]>>; ECRIT <[email-masked]<mailto:[email-masked]>>
Objet : [EXT]Re: [Ecrit] planned-changes: two questions

No.

Brian

Brian

Inline.

Guy

-----Message d'origine-----
De : Brian Rosen <[email-masked]<mailto:[email-masked]>>
Envoyé : 31 août 2021 08:11
À : Caron, Guy <[email-masked]<mailto:[email-masked]>>
Cc : Randall Gellens <[email-masked]<mailto:[email-masked]>>; ECRIT <[email-masked]<mailto:[email-masked]>>
Objet : [EXT]Re: [Ecrit] planned-changes: two questions

Brian

Guy

-----Message d'origine-----

So

Brian

--Randall

---

From: Brian Rosen <[email-masked]>
Date: Tue, 31 Aug 2021 17:11:51 -0400

It could limit it, but that would be a problem if it limited it such that a large planned change properly registered couldn’t work.  In some areas, they change hundreds of thousands of address points in a large annexation.  It’s not typically millions, but you could imagine something like a county that dumps a new Site/Structure list where there wasn’t one before that triggers this kind of notification.

That doesn’t change the need for start and limit if the list can be big.  Lots of systems I know have pretty severe limits on the size of an upload response for interfaces like this.

Hmmm, start and limit go the wrong way.  The notification is the POST.  Start and Limit are for a GET.  We would have to implement an equivalent on the registration.

Brian

> On Aug 31, 2021, at 4:57 PM, Caron, Guy <[email-masked]> wrote:
> 
> On Aug 31, 2021, at 4:38 PM, Caron, Guy <[email-masked] <mailto:[email-masked]>> wrote:
>  
> À : Randall Gellens <[email-masked] <mailto:[email-masked]>>
> Cc : Caron, Guy <[email-masked] <mailto:[email-masked]>>; ECRIT <[email-masked] <mailto:[email-masked]>>

---

From: "Randall Gellens" <[email-masked]>
Date: Tue, 31 Aug 2021 14:49:59 -0700

The IDs are entirely up to the server.  The server can aggregate them.

--Randall

On 31 Aug 2021, at 14:11, Brian Rosen wrote:

> It could limit it, but that would be a problem if it limited it such 
> that a large planned change properly registered couldn’t work.  In 
> some areas, they change hundreds of thousands of address points in a 
> large annexation.  It’s not typically millions, but you could 
> imagine something like a county that dumps a new Site/Structure list 
> where there wasn’t one before that triggers this kind of 
> notification.
>
> That doesn’t change the need for start and limit if the list can be 
> big.  Lots of systems I know have pretty severe limits on the size of 
> an upload response for interfaces like this.
>
> Hmmm, start and limit go the wrong way.  The notification is the POST. 
>  Start and Limit are for a GET.  We would have to implement an 
> equivalent on the registration.
>
> Brian
>
>> If we make <revalidateLocation> a list of IDs, one notification per 
>> URI per planned change would be sufficient.
>>
>> Guy
>>
>> There is one URI, but many IDs, one per unique record at the LoST 
>> server that is involved in a planned change.  The one URI will 
>> receive one notification per ID it has registered for.
>>
>>
>>
>>
>>
>> On Aug 31, 2021, at 2:56 PM, Randall Gellens 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> i understand that the concern is allowing a client to leverage the 
>> LoST server to attack a large number of targets, I'm just not clear 
>> mechanically how such leverage potentially works. Each validation 
>> query can store a URI, and that URI may get associated with a large 
>> number of locations. Maybe there's a street name change or an 
>> annexation. So maybe thousands or tens or hundreds of thousands of 
>> locations are potentially invalidated. They all have the same URI 
>> associated with them, so the LoST server connects to the URI once and 
>> POSTs one notification, no?
>> --Randall
>> large planned change occurred, the victim could receive a large 
>> number of notifications it didn’t expect.
>>
>> On Aug 31, 2021, at 1:35 PM, Randall Gellens 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Regarding opening a new DoS, I guess I'm not following. Wouldn't this 
>> case be covered by the security considerations in RFC 5222?
>>
>> identify the client, and anything can occur after it (meaning a slash 
>> and whatever)?  If we do that, then how would delete the 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> <https://www.ietf.org/mailman/listinfo/ecrit>
>>
>> <https://www.ietf.org/mailman/listinfo/ecrit>

---

From: "Caron, Guy" <[email-masked]>
Date: Tue, 31 Aug 2021 21:49:58 +0000

Well, this notification process is for planned changes and in the majority of cases, planned changes will trigger notification in advance of the change. It actually may be a benefit to the Server to send notifications in bundles, especially if the planned change is large. That way it could somewhat control the surge of revalidations coming to it.

Guy

Envoyé : 31 août 2021 17:12

Brian

On Aug 31, 2021, at 4:57 PM, Caron, Guy <[email-masked]<mailto:[email-masked]>> wrote:

Guy

Brian

Guy

No.

Brian

Brian

Inline.

Guy

-----Message d'origine-----
De : Brian Rosen <[email-masked]<mailto:[email-masked]>>
Envoyé : 31 août 2021 08:11
À : Caron, Guy <[email-masked]<mailto:[email-masked]>>
Cc : Randall Gellens <[email-masked]<mailto:[email-masked]>>; ECRIT <[email-masked]<mailto:[email-masked]>>
Objet : [EXT]Re: [Ecrit] planned-changes: two questions

Brian

Guy

-----Message d'origine-----

So

Brian

--Randall