Hi Magnus,
Thanks for the thorough review of the document! In parallel to discussing CC on the thread opened by Med, let me ask you something regarding
return routability check.
The complete exchange for a subscription operation would be:
1) xTR->MS (Map-Request)
2) MS->xTR (Map-Notify)
3) xTR->MS (Map-Notify-Ack)
It is true that 3) is not explicitly stated on the PubSub document today, but it is required to align with RFC9301. We should update the PubSub doc to explicitly mention 3). I believe that having
1)+2)+3) explicitly stated should address your concerns regarding return routability check, what do you think?
Thanks!
Alberto
From: Magnus Westerlund via Datatracker <noreply@xxxxxxxx>
Date: Tuesday, January 24, 2023 at 2:21 PM
To: 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: Tsvart last call review of draft-ietf-lisp-pubsub-10
Reviewer: Magnus Westerlund
Review result: Not Ready
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.
My review comments are:
A. Appear the system lacks any type of authentication of the xTR and also
does not have any system for verifying that a subsequent subscription request
or update is coming from the same xTR as the previous subscription request. To
me it appears to leave the system vulnerable to an attacker taking over the
subscription from the intended xTR preventing the xTR from receiving any
Map-Notify upon changes of the mapping. Thus, enabling an attacker that have
managed to poison a resolver cache state to maintain there state despite
attempts to get further updates.
B. The system lacks any verification that the xTR actually are present on
the location that a sub came in from. This enables an attacker to spoof a large
number of subs from various locations using spoofed source address information.
If I understand this correctly when a map-notify is sent for one of these it
will retransmit them several times (three times with 3-second interval
recommended). Thus, one attack packet results in 4 packets when a Map is
updated. Which may also be impacted by the attacker. Thus, setting up a
time-bomb with many subscription and then trigger it with a Map update in the
map server. The only protection discussed is rate limiting subscriber requests
which will not be effective in regards to the time bomb as that only impacts
time to establish the timebomb with sufficient number of subs.
C. When a Map-Notify is to be sent there are no discussion in regards to
congestion control of the transmission of the Map-Notify. As the Map-Notify
appear to be unicast IP/UDP packets being sent one per subscriber at the time
an updated mapping is registered with the map-server all these messages will be
generated. There need to be some rate limiting for this transmission to prevent
congestion near the map-server. If sufficient number of subs are in place also
the retransmission will have to be rate limited as not all Map-Notify messages
will have been sent when its time to start to perform retransmissions.
D. Map-Notify-Ack implosion risks. So the Map-Notify-ACK rate will be a
large fraction of the Map-Notify messages being sent. Thus, if they are sent
out at high rate the return traffic to the Map-Server will be of similar rate.
Thus, there appear to be need for consideration of also this traffic. The
Map-Notify and their ACKs requires tracking thus, if they are not timely
processed or dropped in the return path there will be more Map-Notify and ACKs
being sent and received. Thus, the system if ending up in overload will not
shed us much load as it could have had it processed properly.
E. I also noted that the DDoS Attack mitigation (Section 7.2) thinks it
can limit the load by rate limiting the number of Map-Notify per xTR-ID, which
unless I missed something important although potentially relevant, it doesn’t
cover the rate from many xTR-ID setup using spoofed IDs. Also shedding subs
when to many xTR-ID are present have some service issues as it will degrade the
service also to non-malicous xTRs. And I didn’t see any discussion of any
method for telling the xTR that its subscription have been terminated. So how
does the xTR detect that it doesn’t get subscriptions?
To me it appear this protocol has worked hard on ensuring that the xTR doesn’t
get outdated information. However the aspect of how one can bring down the
map-server and its service has not gotten sufficient thought and mitigations.
For example I think a return routability check for each xTR-ID when they
request their first subscription would help prevent source spoofed subs.
Next, I think the rate limiting and retransmission interaction for Map-Notify
and the impact of the Map-Notify-Ack tracking needs discussion to ensure that
congestion is not created near the map-server. Especially as the Map-Notify-Ack
will impact the possibility to service independent Map-requests to this
Map-server.
Protection against hijacking of xTR's existing subscription likely also have to
be considered.
So in conclusion unless my review missed important mechanism in the rest of the
LISP ecosystem that prevents these this document needs more work before being
ready as a standards track document.
Cheers
Magnus Westerlund
