Hi Magnus, Thanks for the follow-up.
Please see inline. Cheers, Med De : Magnus Westerlund <magnus.westerl...@ericsson.com> Envoyé : vendredi 3 février 2023 10:49 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; Alberto Rodriguez-Natal (natal) <na...@cisco.com>; tsv-...@ietf.org Cc : draft-ietf-lisp-pubsub....@ietf.org; last-c...@ietf.org; lisp@ietf.org 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: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Date: Monday, 30 January 2023 at 13:45 To: Alberto Rodriguez-Natal (natal) <na...@cisco.com<mailto:na...@cisco.com>>, Magnus Westerlund <magnus.westerl...@ericsson.com<mailto:magnus.westerl...@ericsson.com>>, tsv-...@ietf.org<mailto:tsv-...@ietf.org> <tsv-...@ietf.org<mailto:tsv-...@ietf.org>> Cc: draft-ietf-lisp-pubsub....@ietf.org<mailto:draft-ietf-lisp-pubsub....@ietf.org> <draft-ietf-lisp-pubsub....@ietf.org<mailto:draft-ietf-lisp-pubsub....@ietf.org>>, last-c...@ietf.org<mailto:last-c...@ietf.org> <last-c...@ietf.org<mailto:last-c...@ietf.org>>, lisp@ietf.org<mailto:lisp@ietf.org> <lisp@ietf.org<mailto:lisp@ietf.org>> 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) <na...@cisco.com<mailto:na...@cisco.com>> > Envoyé : lundi 30 janvier 2023 12:27 > À : Magnus Westerlund > <magnus.westerl...@ericsson.com<mailto:magnus.westerl...@ericsson.com>>; tsv- > a...@ietf.org<mailto:a...@ietf.org> > Cc : > draft-ietf-lisp-pubsub....@ietf.org<mailto:draft-ietf-lisp-pubsub....@ietf.org>; > last-c...@ietf.org<mailto:last-c...@ietf.org>; > lisp@ietf.org<mailto:lisp@ietf.org> > Objet : Re: Tsvart last call review of draft-ietf-lisp-pubsub-10 > > Hi Magnus, > > Thanks again, please see inline. > > Alberto > > From: Magnus Westerlund > <magnus.westerl...@ericsson.com<mailto:magnus.westerl...@ericsson.com>> > Date: Monday, January 30, 2023 at 9:46 AM > To: Alberto Rodriguez-Natal (natal) > <na...@cisco.com<mailto:na...@cisco.com>>, tsv- > a...@ietf.org<mailto:a...@ietf.org> > <tsv-...@ietf.org<mailto:tsv-...@ietf.org>> > Cc: > draft-ietf-lisp-pubsub....@ietf.org<mailto:draft-ietf-lisp-pubsub....@ietf.org> > <draft-ietf-lisp- > pubsub....@ietf.org<mailto:pubsub....@ietf.org>>, > last-c...@ietf.org<mailto:last-c...@ietf.org> > <last-c...@ietf.org<mailto:last-c...@ietf.org>>, > lisp@ietf.org<mailto:lisp@ietf.org> <lisp@ietf.org<mailto:lisp@ietf.org>> > 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 lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
