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@ietf.org 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