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? It would be good to have understanding of the amplification factor here that an attacker gets out it.
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. 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.boucadair@xxxxxxxxxx <mohamed.boucadair@xxxxxxxxxx>
Date: Monday, 30 January 2023 at 13:45
To: Alberto Rodriguez-Natal (natal) <natal@xxxxxxxxx>, Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>, tsv-art@xxxxxxxx <tsv-art@xxxxxxxx>
Cc: draft-ietf-lisp-pubsub.all@xxxxxxxx <draft-ietf-lisp-pubsub.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>, lisp@xxxxxxxx <lisp@xxxxxxxx>
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) <natal@xxxxxxxxx>
> Envoyé : lundi 30 janvier 2023 12:27
> À : Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>; tsv-
> art@xxxxxxxx
> Cc : draft-ietf-lisp-pubsub.all@xxxxxxxx; last-call@xxxxxxxx;
> lisp@xxxxxxxx
> Objet : Re: Tsvart last call review of draft-ietf-lisp-pubsub-10
>
> Hi Magnus,
>
> Thanks again, please see inline.
>
> Alberto
>
> From: Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>
> Date: Monday, January 30, 2023 at 9:46 AM
> To: Alberto Rodriguez-Natal (natal) <natal@xxxxxxxxx>, tsv-
> art@xxxxxxxx <tsv-art@xxxxxxxx>
> Cc: draft-ietf-lisp-pubsub.all@xxxxxxxx <draft-ietf-lisp-
> pubsub.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>,
> lisp@xxxxxxxx <lisp@xxxxxxxx>
> 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.
|
