|
Hi Magnus, Med, Thanks for all the help and suggestions during the review process Magnus, I think they have greatly improved the document.
I think it is reasonable to add an applicability statement. As Med points out, we already have some text on the spec that we could update and use. We’ll include the statement in the next revision. Thanks! Alberto
From: mohamed.boucadair@xxxxxxxxxx <mohamed.boucadair@xxxxxxxxxx> 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 <magnus.westerlund@xxxxxxxxxxxx>
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> 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> 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
Hi Magnus,
Thanks for the follow-up. Please see inline.
Cheers, Med De : Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>
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>
Re-, _________________________________________________________________________________________________________________________
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.
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
