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

[Joel Halpern <[e-mail]>]

IIf I am understanding you properly, the security considerations in the 
draft can be stated more clearly and strongly to show that the DDOS 
attack by unknown entities is not possible.  And presumably that a known 
entity pounding the system with subscriptions would cause an alarm and 
response.

Yours,

Joel

On 2/15/2023 6:10 PM, Alberto Rodriguez-Natal (natal) wrote:
>
> Joel,
>
> Currently LISP-SEC is required in PubSub to 1) establish a security 
> association (PubSubKey) between ITR and MS when none is present, and 
> 2) reset the nonce state when needed. When used, the assumptions from 
> LISP-SEC are carried over (secured MR-MS communication channel, etc).
>
> When pre-shared keys are used for PubSubKeys and the nonces are kept 
> reliably  (e.g. in persistent storage), then LISP-SEC can be optional.
>
> Note that despite LISP-SEC being used or not, the general 
> considerations from 9301 regarding integrity protection, etc for 
> Map-Request are still valid here.
>
> Thanks,
>
> Alberto
>
> *From: *Joel Halpern <[e-mail]>
> *Date: *Wednesday, February 15, 2023 at 7:48 PM
> *To: *[e-mail] <[e-mail]>, 
> 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: [lisp] Tsvart last call review of draft-ietf-lisp-pubsub-10
>
> 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]> <mailto:[e-mail]>
>     *Envoyé :* mercredi 15 février 2023 17:32
>     *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
>     <mailto:[e-mail]>; Magnus Westerlund
>     <[e-mail]>
>     <mailto:[e-mail]>; Alberto Rodriguez-Natal
>     (natal) <[e-mail]> <mailto:[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.
>