Hi Jari, On Aug 29, 2011, at 23:54 , Jari Arkko wrote:
> I have reviewed this draft. This is another well written and easy to > understand document. Thank you for that. > > I only found minor editorial issues, one security aspect that you should > document, and couple of small technical comments. I have sent the document > forward to IETF Last Call anyway. Please revise the draft as soon as you can > (even during Last Call). Since the Gen-ART review is also available we were thinking to gather all changes and submit one single update. (we answer the Gen-ART comments in a separate mail) > Ask me if something was unclear or I missed something. > We put our answers inline. As you will see there is only one point were we are not sure how to proceed. > Technical: > >> The feature >> introduced by Map-Version numbers is the possibility of blocking >> traffic from ITRs not using the latest mapping. Indeed, after a >> certain number of retries, if the Destination Map-Version number >> in the packets is not updated, the ETR MAY silently drop packets >> with a stale Map-Version number. This because either the ITR is >> refusing to use the mapping for which the ETR is authoritative or >> (worse) it might be some form of attack. > > I have two small comments about this. First, since an attack could spoof the > source address, it is important to restrict the blocking to the offending > traffic, not all traffic from a given ITR address. And this is your > intention, as can be seen from the second sentence. Could you make the > following change to make this even clearer in the first sentence as well: > s/blocking traffic from ITRs not using the latest mapping/blocking traffic > not using the latest mapping/. Yes this was our intention. We will change the text as you suggest. > > Second, I'm not sure I understand the different failure cases here. What if > there's a network issue that causes unidirectional connectivity? We'd receive > lisp encapsulated packets, but our attempts to send commands to update the > mapping would be unsuccessful, as the traffic does not get through. In light > of this, is the right action to start dropping packets on our side? Or maybe > there is something else in Lisp that prevents us from getting into this > situation. Please explain. And if you are not sure what the implications are, > please indicate that in the text. This is an interesting scenario. It must be noted that the return path is not the same as the forward path. On the forward path there are packets arriving to the ETR with a stale version number. These packets follow the data path. The ETR seeing the stale mapping will send a Map-Request with SMR bit set. This packet will follow the control path through [LISP-MS] and [LISP-ALT] or any future mapping system. Now, if the reverse control path fails it means that the there are important partitioning problem on the mapping system. Do you think we should take an explicit action in this case? Note as well that we use "MAY". What we want to say is "somebody has a stale mapping and does want or is not able to update hence the ETR is allowed to ignore that traffic if it wish". > > >> 3. The packet arrives with a Source Map-Version number smaller >> (i.e., older) than the one stored in the local EID-to-RLOC Cache. >> Such a case is not valid w.r.t. the specifications. Indeed, if >> the mapping is already present in the EID-to-RLOC Cache, this >> means that an explicit Map-Request has been sent and a Map-Reply >> has been received from an authoritative source. Assuming that >> the mapping system is not corrupted anyhow, the Map-Version in >> the EID-to-RLOC Cache is the correct one and the packet MAY be >> silently dropped. >> > > I worry that there's a dependency on something which cannot be fully secured > in the real-world, and if someone starts to drop packets due to an > inconsistency there is no easy way to recover. I would suggest adding > something to the security considerations section about reliance on the > security of the mapping system and aggressive drop policies leading to the > possibility of difficult recovery from a temporary mapping system issue. Again we put a "MAY" and we are not suggesting aggressive drop. But we agree that we should more explicitly state in the security section that versioning assumes a secured mapping system. If the mapping system is compromised somehow versioning loses its robustness. > >> Once no more traffic is received by the RLOC, because all sites have >> updated the mapping, it can be shut down safely. > > Technically, there might be a mapping on some other site that has not had a > reason to send a packet yet. But if it then sends a packet, it might use a > locally cached copy of the mapping and the packet goes to the wrong place. > > Perhaps you should clarify this. E.g. " ... received by the RLOC, it can be > shut down in relatively safety, because at least all sites actively using the > mapping have updated it." Yes. We will clarify this point as you suggest. > > > Editorial: > >> This document describes the LISP Map-Versioning mechanism, which >> provides in-packet information about EID-to-RLOC mappings used to >> encapsulate LISP data packets. The proposed approach is based on >> associating a version number to EID-to-RLOC mappings and transport >> such a version number in the LISP specific header of LISP- >> encapsulated packets. LISP Map-Versioning is particularly useful to >> inform communicating xTRs about modifications of the mappings used to >> encapsulate packets. The mechanism is transparent to legacy >> implementations, since in the LISP-specific header and in the Map >> Records, bits used for Map-Versioning can be safely ignored by xTRs >> that do not support the mechanism. > > You should expand EID, RLOC, and xTR, as this is the abstract (it can be read > by someone without seeing the rest of the document). OK. > >> When Map-Versioning is used, LISP-encapsulated data packets contain >> the version number of the two mappings used to select the RLOCs in >> the outer header (i.e., both source and destination). These version >> numbers are encoded in the 24 low-order bits of the first longword of >> the LISP header and indicated by a specific bit in the flags (first 8 >> high-order bits of the first longword of the LISP header). Note that >> not all packets need to carry version numbers. > > I'd prefer seeing a reference to draft-ietf-lisp and section number that > defines the Lisp header. We will put the reference. > >> The Map-Request will either trigger a Map-Request back >> using the SMR bit or it will piggyback the newer mapping. These >> are not new mechanisms; how to SMR or piggyback mappings in Map- >> Request messages is already described in [I-D.ietf-lisp], > > Expand SMR. > OK. > >> A Proxy-ETR does not have any mapping, since it just decapsulate >> packets arriving from LISP site. > > s/decapsulate/decapsulates/ > Thanks. Luigi on behalf of all authors. > Jari > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
