Re: [Ecrit] planned-changes: two questions

[Randall Gellens <[e-mail]>]

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
>
>> On Aug 31, 2021, at 4:57 PM, Caron, Guy <[e-mail]> wrote:
>>
>> The size of the list could be a policy at the Server.
>>
>> Guy
>>
>> De : Brian Rosen <[e-mail]>
>> Envoyé : 31 août 2021 16:55
>> À : Caron, Guy <[e-mail]>
>> Cc : Randall Gellens <[e-mail]>rg>; ECRIT 
>> <[e-mail]>
>> Objet : [EXT]Re: [Ecrit] planned-changes: two questions
>>
>> 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 <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> If we make <revalidateLocation> a list of IDs, one notification per 
>> URI per planned change would be sufficient.
>>
>> Guy
>>
>> De : Brian Rosen <[e-mail] <mailto:[e-mail]>>
>> Envoyé : 31 août 2021 15:35
>> À : Randall Gellens <[e-mail] 
>> <mailto:[e-mail]>>
>> Cc : Caron, Guy <[e-mail] <mailto:[e-mail]>>; ECRIT 
>> <[e-mail] <mailto:[e-mail]>>
>> Objet : [EXT]Re: [Ecrit] planned-changes: two questions
>>
>> 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 
>> <[e-mail] <mailto:[e-mail]>> 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 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
>>
>>
>>
>>
>> On Aug 31, 2021, at 1:35 PM, Randall Gellens 
>> <[e-mail] <mailto:[e-mail]>> 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 31 Aug 2021, at 10:27, Brian Rosen wrote:
>> 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 <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Inline.
>>
>> Guy
>>
>> -----Message d'origine-----
>> De : Brian Rosen <[e-mail] <mailto:[e-mail]>>
>> Envoyé : 31 août 2021 08:11
>> À : Caron, Guy <[e-mail] <mailto:[e-mail]>>
>> Cc : Randall Gellens <[e-mail] 
>> <mailto:[e-mail]>>; ECRIT <[e-mail] 
>> <mailto:[e-mail]>>
>> 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.
>>
>> 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 <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> 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 <[e-mail] <mailto:[e-mail]>> 
>> De la part de Brian Rosen Envoyé :
>> 30 août 2021 11:22 À : Randall Gellens <[e-mail] 
>> <mailto:[e-mail]>> Cc
>> : ECRIT <[e-mail] <mailto:[e-mail]>> Objet : [EXT]Re: 
>> [Ecrit] planned-changes: two
>> questions
>>
>> 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 
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>> 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
>>
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/ecrit 
>> <https://www.ietf.org/mailman/listinfo/ecrit>
>>
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/ecrit 
>> <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
>>
>> ------------------------------------------------------------------------------
>> External Email: Please use caution when opening links and attachments 
>> / Courriel externe: Soyez prudent avec les liens et documents joints
>>
>>
>>
>> External Email: Please use caution when opening links and attachments 
>> / Courriel externe: Soyez prudent avec les liens et documents joints
>>
>> External Email: Please use caution when opening links and attachments 
>> / Courriel externe: Soyez prudent avec les liens et documents joints