Re: [Tsv-art] [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10

[Joel Halpern <[e-mail]>]

Well, the security folks usually want a stateless solution to this sort 
of problem.  The nonce increment requries keeping state per pending 
correspondent.

Yours,

Joel

On 2/15/2023 4:46 PM, Dino Farinacci wrote:
> Tell me what you all think.  Can the map-server just store the nonce 
> and then the next Map-Request have the map-server require nance+1?
>
> Stops reply attacks at only the cost of storing an additional 64 bits. 
>  Do you think that solves the problem?
>
> Dino
>
>> On Feb 15, 2023, at 10:49 AM, Joel Halpern <[e-mail]> wrote:
>>
>> 
>>
>> Given that a lot of the use cases have a lot of legitimate users, I 
>> think magnus concern is reasonable, but I am willing to settle for less.
>>
>> If I am reading things right, the xTR<->Map_Resolver exchanges for 
>> pub-sub SHOULD use LISP-SEC.
>>
>> And the Map-Resolver<->Map Server exchanges should magically know 
>> that the Map Resolvers are doing so?
>>
>> The SHOULD needs some explanation as to when it is okay not to, or 
>> else it ought to be upgraded to a MUST.
>>
>> The Map Server requirement seems like it would benefit from some 
>> explanation as to how this knowledge would exist.
>>
>> Yours,
>>
>> Joel
>>
>> PS: If LISP Sec can be used along the lines Dino indicated, taht 
>> would be a nice way to combine some of the protections and better 
>> address the issues.
>>
>> On 2/15/2023 1:36 PM, [e-mail] wrote:
>>>
>>> Hi Joel,
>>>
>>> The proposal is not to restrict the usage of PubSub to “limited 
>>> domains” as per RFC8799. Please refer to 
>>> https://github.com/boucadair/draft-ietf-lisp-pubsub/pull/16/files to 
>>> see the text we are planning to include as applicability scope.
>>>
>>> I think this is a reasonable suggestion especially that we want to 
>>> leverage 9301/9303.
>>>
>>> Thank you.
>>>
>>> Cheers,
>>>
>>> Med
>>>
>>> *De :*Joel Halpern <[e-mail]>
>>> *Envoyé :* mercredi 15 février 2023 17:32
>>> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>; 
>>> Magnus Westerlund <[e-mail]>; Alberto 
>>> Rodriguez-Natal (natal) <[e-mail]>; [e-mail]
>>> *Cc :* [e-mail]; [e-mail]; 
>>> [e-mail]
>>> *Objet :* Re: [lisp] Tsvart last call review of 
>>> draft-ietf-lisp-pubsub-10
>>>
>>> Hmmm.
>>>
>>> Maybe I misunderstood, but a lot of the uses I have seen for the 
>>> pub-sub mechanism do not seem to be limited enough to qualify for 
>>> being a limited domain.
>>>
>>> On the other hand, the general idea of the DDOS prevention mechanism 
>>> (modeled loosely on the prevention of TCP State attacks) seems 
>>> valuable and easy to add.  If a Map Server serving a broad community 
>>> gets a pub-sub subscription request, and it is under any significant 
>>> load, it can
>>>
>>> 1) craft a security token hashing the request, the current time, and 
>>> a private key (and whatever else security says is needed
>>>
>>> 2) Sending the token and time back to the requestor in an error
>>>
>>> 3) When the requestor sends back the request, it includes the 
>>> timestamp and token.  The server only processes the request if the 
>>> information validates.
>>>
>>> This validates that the response actually went to the requestor, and 
>>> was a real request.  Yes, it slightly slows down the pub-sub 
>>> registration under load.
>>>
>>> I don't know if I caught all of Magnus' issue, but this would seem a 
>>> good thing to do.
>>>
>>> Yours,
>>>
>>> Joel
>>>
>>> On 2/15/2023 3:24 AM, [e-mail] wrote:
>>>
>>>     Hi Magnus,
>>>
>>>     Thank you for the follow-up.
>>>
>>>     First, your observation on the verification procedure at the
>>>     Map-Server is fair. We have documented the issue in
>>>     draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret
>>>     <https://www.ietf.org/archive/id/draft-boucadair-lisp-pubsub-flow-examples-03.html#name-failed-notification-with-ret>
>>>     and discussed the alternative to strengthen the verification
>>>     based on the timestamp but we had also the constraint to
>>>     navigate in the LISP environment where LISP-SEC messages are not
>>>     timestamped. We think that the procedure in the draft is a good
>>>     compromise of what we can achieve given that constraint. FWIW,
>>>     the full reasoning is available at: timestamp to prevent replay
>>>     attacks · Issue #1 · boucadair/draft-ietf-lisp-pubsub
>>>     (github.com)
>>>     <https://github.com/boucadair/draft-ietf-lisp-pubsub/issues/1>.
>>>
>>>     Second, I support your proposal to add an applicability
>>>     statement to the document. The content will be basically moving
>>>     (and adjusting the language) the following text in Section 7 to
>>>     that section:
>>>
>>>     OLD:
>>>
>>>        It is also RECOMMENDED that the Map-Resolver
>>>
>>>        verifies that the xTR is allowed to use PubSub and to use the
>>>     xTR-ID
>>>
>>>        and ITR-RLOCs included in the Map-Request. Map-Servers SHOULD be
>>>
>>>     configured to only accept subscription requests from Map-Resolvers
>>>
>>>        that verify Map-Requests as previously described.
>>>
>>>     I let Alberto further comment as appropriate.
>>>
>>>     Cheers,
>>>
>>>     Med
>>>
>>>     *De :*Magnus Westerlund <[e-mail]>
>>>     <mailto:[e-mail]>
>>>     *Envoyé :* mercredi 15 février 2023 08:33
>>>     *À :* Alberto Rodriguez-Natal (natal) <[e-mail]>
>>>     <mailto:[e-mail]>; BOUCADAIR Mohamed INNOV/NET
>>>     <[e-mail]>
>>>     <mailto:[e-mail]>; [e-mail]
>>>     *Cc :* [e-mail]; [e-mail];
>>>     [e-mail]
>>>     *Objet :* Re: Tsvart last call review of draft-ietf-lisp-pubsub-10
>>>
>>>     Hi,
>>>
>>>     Thanks for the many improvements and I think this is likely safe
>>>     enough for limited deployments when the Map-Server are not open
>>>     to any xTR to send requests. I don’t think this is safe enough
>>>     for general Internet usage for two reasons. First, the
>>>     verification procedure forces the MAP-Server to hold state
>>>     rather than the requestor and the messages only. Secondly, a lot
>>>     of the security procedures are only RECOMMEND/SHOULD. For an
>>>     open Internet I think a more tightly defined security mechanisms
>>>     and protection profile should be specified.
>>>
>>>     Thus, my recommendation would be to add an applicability
>>>     statement to the document making clear that this is intended for
>>>     the deployments with more limited access to Map-Servers than
>>>     what an open internet deployment provides.
>>>
>>>     Cheers
>>>
>>>     Magnus Westerlund
>>>
>>>     *From: *Alberto Rodriguez-Natal (natal) <[e-mail]>
>>>     *Date: *Monday, 13 February 2023 at 20:26
>>>     *To: *[e-mail]
>>>     <[e-mail]>, Magnus Westerlund
>>>     <[e-mail]>, [e-mail]
>>>     <[e-mail]>
>>>     *Cc: *[e-mail]
>>>     <[e-mail]>, [e-mail]
>>>     <[e-mail]>, [e-mail] <[e-mail]>
>>>     *Subject: *Re: Tsvart last call review of draft-ietf-lisp-pubsub-10
>>>
>>>     Hi Magnus,
>>>
>>>     Just FYI, we have just published a new revision that further
>>>     polishes some details.
>>>
>>>     https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-12
>>>
>>>     https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-pubsub-12
>>>
>>>     Thanks!
>>>
>>>     Alberto
>>>
>>>     *From: *[e-mail] <[e-mail]>
>>>     *Date: *Friday, February 10, 2023 at 3:55 PM
>>>     *To: *Magnus Westerlund <[e-mail]>,
>>>     Alberto Rodriguez-Natal (natal) <[e-mail]>,
>>>     [e-mail] <[e-mail]>
>>>     *Cc: *[e-mail]
>>>     <[e-mail]>, [e-mail]
>>>     <[e-mail]>, [e-mail] <[e-mail]>
>>>     *Subject: *RE: Tsvart last call review of draft-ietf-lisp-pubsub-10
>>>
>>>     Hi Magnus,
>>>
>>>     FWIW, an updated version that implements the changes that were
>>>     discussed in this thread is now online:
>>>
>>>     https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-pubsub-11
>>>     <https://author-tools.ietf.org/iddiff?url2=draft-ietf-lisp-pubsub-11>
>>>
>>>     Cheers,
>>>
>>>     Med
>>>
>>>     *De :*BOUCADAIR Mohamed INNOV/NET
>>>     *Envoyé :* mardi 7 février 2023 13:15
>>>     *À :* 'Magnus Westerlund' <[e-mail]>;
>>>     Alberto Rodriguez-Natal (natal) <[e-mail]>; [e-mail]
>>>     *Cc :* [e-mail]; [e-mail];
>>>     [e-mail]
>>>     *Objet :* RE: Tsvart last call review of draft-ietf-lisp-pubsub-10
>>>
>>>     Hi Magnus,
>>>
>>>     Thanks for the follow-up.
>>>
>>>     Please see inline.
>>>
>>>     Cheers,
>>>
>>>     Med
>>>
>>>     *De :*Magnus Westerlund <[e-mail]>
>>>     *Envoyé :* vendredi 3 février 2023 10:49
>>>     *À :* BOUCADAIR Mohamed INNOV/NET
>>>     <[e-mail]>; Alberto Rodriguez-Natal (natal)
>>>     <[e-mail]>; [e-mail]
>>>     *Cc :* [e-mail]; [e-mail];
>>>     [e-mail]
>>>     *Objet :* Re: Tsvart last call review of draft-ietf-lisp-pubsub-10
>>>
>>>     Hi Med,
>>>
>>>     Thanks, so that at least you can have a clear notification of
>>>     the removal unless the packet loss rate is to high. What, is
>>>     less ideal is the number of total messages that is going to be
>>>     sent here towards the source address that sent a Map-Register?
>>>
>>>     */[Med] I guess you meant Map-Request. Yes, there is a balance
>>>     between the chattiness vs. reverse-routeablity checks and also
>>>     the constraints imposed by the base spec for retransmission
>>>     Map-Notifies. Having an explicit indication is superior as it
>>>     allows an xTR to reinstall the state, otherwise it will be out
>>>     of sync. /*
>>>
>>>     *//*
>>>
>>>     It would be good to have understanding of the amplification
>>>     factor here that an attacker gets out it.
>>>
>>>     */[Med] Such attacks assume that a Map-Request passes the
>>>     authentication checks. This is typically the case of replayed
>>>     Map-Requests. As you can see in
>>>     https://datatracker.ietf.org/doc/draft-boucadair-lisp-pubsub-flow-examples/,
>>>     a check based on the nonce would be sufficient to detect
>>>     replayed messages: the nonce has to be greater than the local
>>>     one. The message will be then silently ignored. We will be
>>>     adding more details about nonce checks to the draft./*
>>>
>>>     *//*
>>>
>>>     Also beyond rate limiting, is there a possibility here to reject
>>>     the MAP-requests from a source address, without causing a denial
>>>     of service attack possibility? My shallow review seem to
>>>     indicate that there exist such a risk. What I am considering is
>>>     that there is a legit xTR (B) with IP (IP-B). If the attacker
>>>     sends a MAP-Request with nonce-A, with IP source address IP-B.
>>>
>>>     */[Med] If the nonce checks are in place, this request will be
>>>     silently discarded./*
>>>
>>>     *//*
>>>
>>>     The Map-Notify will go to B. B can’t map this to a request it
>>>     made as no Nonce matches what it sends and discards the message.
>>>     Thus, the map server getting a mix of legit and spoofed requests
>>>     may decide to band IP-B from asking things, thus enabling a
>>>     denial of service on B.
>>>
>>>     The above worries me a bit as some mitigation may have really
>>>     unwanted effects here.
>>>
>>>     Cheers
>>>
>>>     Magnus
>>>
>>>     *From: *[e-mail] <[e-mail]>
>>>     *Date: *Monday, 30 January 2023 at 13:45
>>>     *To: *Alberto Rodriguez-Natal (natal) <[e-mail]>, Magnus
>>>     Westerlund <[e-mail]>, [e-mail]
>>>     <[e-mail]>
>>>     *Cc: *[e-mail]
>>>     <[e-mail]>, [e-mail]
>>>     <[e-mail]>, [e-mail] <[e-mail]>
>>>     *Subject: *RE: Tsvart last call review of draft-ietf-lisp-pubsub-10
>>>
>>>     Re-,
>>>
>>>     Please see inline.
>>>
>>>     Cheers,
>>>     Med
>>>
>>>     > -----Message d'origine-----
>>>     > De : Alberto Rodriguez-Natal (natal) <[e-mail]>
>>>     > Envoyé : lundi 30 janvier 2023 12:27
>>>     > À : Magnus Westerlund <[e-mail]>; tsv-
>>>     > [e-mail]
>>>     > Cc : [e-mail]; [e-mail];
>>>     > [e-mail]
>>>     > Objet : Re: Tsvart last call review of draft-ietf-lisp-pubsub-10
>>>     >
>>>     > Hi Magnus,
>>>     >
>>>     > Thanks again, please see inline.
>>>     >
>>>     > Alberto
>>>     >
>>>     > From: Magnus Westerlund <[e-mail]>
>>>     > Date: Monday, January 30, 2023 at 9:46 AM
>>>     > To: Alberto Rodriguez-Natal (natal) <[e-mail]>, tsv-
>>>     > [e-mail] <[e-mail]>
>>>     > Cc: [e-mail] <draft-ietf-lisp-
>>>     > [e-mail]>, [e-mail] <[e-mail]>,
>>>     > [e-mail] <[e-mail]>
>>>     > Subject: Re: Tsvart last call review of draft-ietf-lisp-pubsub-10
>>>     > Hi Alberto,
>>>     >
>>>     > I think the below maybe works, but I like to point out that the
>>>     > Map-Server per the below is likely a larger DDoS traffic reflector
>>>     > than if you require a one-to-one exchange where each subscription
>>>     > request only results in a single response message. Using Map-
>>>     > Notify and requiring Ack will result in that at least 3 Map-
>>>     > Notifies are being sent.
>>>     >
>>>     > [AR] Right, but this is required if we want to align with RFC9301,
>>>     > afaik.
>>>
>>>     [Med] ACK. RFC9301 says the following:
>>>
>>>        A
>>>        Map-Notify is retransmitted until a Map-Notify-Ack is
>>>     received by the
>>>        Map-Server with the same nonce used in the Map-Notify message.
>>>
>>>     >
>>>     > I am also worried about the state uncertainty here. Because if the
>>>     > client sends Map-Notify-Ack on a Map-Notify it will think the
>>>     > subscription has succeeded, but if that ACK is lost and the
>>>     > MapServer has used up all retransmission it will silently remove
>>>     > the requested subscription. Is that not an issue?
>>>     >
>>>     > [AR] I've been thinking about this as well. Maybe some middle
>>>     > ground, assuming that xTRs can be authenticated to some extend as
>>>     > being discussed in the other email, could be as follows. Rather
>>>     > than wait for the Map-Notify-Ack to mark the subscription state as
>>>     > completed, we still mark the subscription as complete as soon as
>>>     > the Map-Notify is sent. We still wait for the Map-Notify-Ack to be
>>>     > received, and if we exhaust all the retransmissions without
>>>     > receiving it, we don't remove the subscription, we keep it as
>>>     > unacknowledged. However, we only allow the xTR to have a single
>>>     > unacknowledged subscription, subsequent subscription requests from
>>>     > the same xTR will be denied (i.e. Map-Reply returned) until the
>>>     > xTR is able to properly subscribe and acknowledge the previous
>>>     > one. Maybe this could work?
>>>     >
>>>
>>>     [Med] Rather than keeping the state, the Map-Server can remove
>>>     the unacknowledged subscription with a Map-Notify with AFI = 0.
>>>     We may also consider defining a new ACT value so the xTR have a
>>>     hint about why the subscription was removed.
>>>
>>>
>>>
>>>
>>>     _________________________________________________________________________________________________________________________
>>>
>>>       
>>>
>>>     Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>>
>>>     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>>
>>>     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>>
>>>     Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>
>>>       
>>>
>>>     This message and its attachments may contain confidential or privileged information that may be protected by law;
>>>
>>>     they should not be distributed, used or copied without authorisation.
>>>
>>>     If you have received this email in error, please notify the sender and delete this message and its attachments.
>>>
>>>     As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>>
>>>     Thank you.
>>>
>>>     _________________________________________________________________________________________________________________________
>>>
>>>     Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>>
>>>     pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>>
>>>     a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>>
>>>     Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>
>>>     This message and its attachments may contain confidential or privileged information that may be protected by law;
>>>
>>>     they should not be distributed, used or copied without authorisation.
>>>
>>>     If you have received this email in error, please notify the sender and delete this message and its attachments.
>>>
>>>     As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>>
>>>     Thank you.
>>>
>>>
>>>
>>> _________________________________________________________________________________________________________________________
>>>
>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>
>>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>>> they should not be distributed, used or copied without authorisation.
>>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>>> Thank you.
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp