Re: [Last-Call] Tsvart last call review of draft-ietf-lisp-pubsub-10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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) <natal@xxxxxxxxx>
Date: Monday, 13 February 2023 at 20:26
To: mohamed.boucadair@xxxxxxxxxx <mohamed.boucadair@xxxxxxxxxx>, 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

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: mohamed.boucadair@xxxxxxxxxx <mohamed.boucadair@xxxxxxxxxx>
Date: Friday, February 10, 2023 at 3:55 PM
To: Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>, 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 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' <magnus.westerlund@xxxxxxxxxxxx>; Alberto Rodriguez-Natal (natal) <natal@xxxxxxxxx>; 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 for the follow-up.

 

Please see inline.

 

Cheers,

Med

 

De : Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>
Envoyé : vendredi 3 février 2023 10:49
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>; Alberto Rodriguez-Natal (natal) <natal@xxxxxxxxx>; 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 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.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.
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux