We should look at the mechanisms of lisp-sec to see if they can be used for this algorithm. I think the OTK is the token and hash Joel describes below but doesn't include a timestamp.
The algorithm, would require two Map-Requests to be sent, as Joel said, and would add subscription delay. The big benefit is that the map-server doesn't have to hold more client state and can scale better, as Magnus referred to. Dino > On Feb 15, 2023, at 8:32 AM, Joel Halpern <[email protected]> wrote: > > 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, [email protected] 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 >> 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). >> >> 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 <[email protected]> >> Envoyé : mercredi 15 février 2023 08:33 >> À : Alberto Rodriguez-Natal (natal) <[email protected]>; BOUCADAIR Mohamed >> INNOV/NET <[email protected]>; [email protected] >> Cc : [email protected]; [email protected]; [email protected] >> 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) <[email protected]> >> Date: Monday, 13 February 2023 at 20:26 >> To: [email protected] <[email protected]>, Magnus >> Westerlund <[email protected]>, [email protected] >> <[email protected]> >> Cc: [email protected] >> <[email protected]>, [email protected] >> <[email protected]>, [email protected] <[email protected]> >> 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: [email protected] <[email protected]> >> Date: Friday, February 10, 2023 at 3:55 PM >> To: Magnus Westerlund <[email protected]>, Alberto >> Rodriguez-Natal (natal) <[email protected]>, [email protected] >> <[email protected]> >> Cc: [email protected] >> <[email protected]>, [email protected] >> <[email protected]>, [email protected]<[email protected]> >> 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 >> >> Cheers, >> Med >> >> De : BOUCADAIR Mohamed INNOV/NET >> Envoyé : mardi 7 février 2023 13:15 >> À : 'Magnus Westerlund' <[email protected]>; Alberto >> Rodriguez-Natal (natal) <[email protected]>; [email protected] >> Cc : [email protected]; [email protected]; [email protected] >> 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 <[email protected]> >> Envoyé : vendredi 3 février 2023 10:49 >> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; Alberto >> Rodriguez-Natal (natal) <[email protected]>; [email protected] >> Cc : [email protected]; [email protected]; [email protected] >> 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: [email protected] <[email protected]> >> Date: Monday, 30 January 2023 at 13:45 >> To: Alberto Rodriguez-Natal (natal) <[email protected]>, Magnus Westerlund >> <[email protected]>, [email protected]<[email protected]> >> Cc: [email protected] >> <[email protected]>, [email protected] >> <[email protected]>, [email protected]<[email protected]> >> 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) <[email protected]> >> > Envoyé : lundi 30 janvier 2023 12:27 >> > À : Magnus Westerlund <[email protected]>; tsv- >> > [email protected] >> > Cc : [email protected]; [email protected]; >> > [email protected] >> > Objet : Re: Tsvart last call review of draft-ietf-lisp-pubsub-10 >> > >> > Hi Magnus, >> > >> > Thanks again, please see inline. >> > >> > Alberto >> > >> > From: Magnus Westerlund <[email protected]> >> > Date: Monday, January 30, 2023 at 9:46 AM >> > To: Alberto Rodriguez-Natal (natal) <[email protected]>, tsv- >> > [email protected] <[email protected]> >> > Cc: [email protected] <draft-ietf-lisp- >> > [email protected]>, [email protected] <[email protected]>, >> > [email protected] <[email protected]> >> > 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. >> >> >> > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
