Hi Joel, thank you very much for your review. Few comments inline.
On 13 Dec. 2012, at 02:24 , Joel M. Halpern <[email protected]> wrote: > In conjunction with the WG last call on this document, I performed my own > review. > > > I am confused by the attack remediation in section 5.3. This seems t say > that an ETR should reject any packet whose source RLOC is not valid for the > source EID. This would seem to frequently doubling the packet drop for > initial communication between two sites, which seems unfortunate. This > recommendation is repeated in the first bullet of section 11. Is this really > the WG recommendation? Yes and No. This has been discussed several times in between other things. My suggestion is to change the following sentence of section 5.3 from: "the LISP ETR should reject the packet and possibly query the mapping system to obtain a mapping for the encapsulated source EID (HA)." to: "the LISP ETR should reject the packet and query the mapping system to obtain a mapping for the encapsulated source EID (HA). Note that this may increase communication setup latency due to the delay in retrieving a mapping for the source EID on the ETR." I would not mention packet drops since LISP does not enforce any specific action for packets with missing mappings (yes current implementations drop the packets but is not part of the specifications.) > > > Also, I have some minor issues. > Section 5.2.2 on EID-to-RLOC Cache overflow is written as if this can only be > caused by control plane attacks, or by a device performing gleaning. This > seems to ignore one other attack vector. It is not a vector which can inject > fake entries, but it can disrupt operation. Namely, an insider sending > packets to a broad range of EIDs. By assumption, the cache is not big enough > to hold the whole mapping table (otherwise it would not be subject to > overflow). It would therefore seem that this sort of attack could disrupt > valid entries and interfere with proper ITR operation. Shouldn't this be > mentioned? Good point. We can add a small paragraph mentioning it. > > Could / should the caveat about rate limiting queries in section 5.4.1 be > moved up in the section, so that the reader realizes early what is needed? Could: Yes Should: IMO no. Rate Limitation is not the key point of the section. > > I am wondering about the tradeoff of including DDT in this document. On the > one hand, DDT is where we likely are going. On the other hand, including > that material will mean that this document gets an RFC Editor hold until LISP > DDT is published. Would it make more sense to defer the DDT specific section > to the DDT document? Another good point but actually goes beyond DDT IMO. If we put ALT and MS make sense to me to put DDT as well. > > Editorial: > The title of section 5.3, "Attacks not leveraging on the LISP header" > seems to have a grammatical error. I think the word "on" is extraneous. > (And similarly for section 5.4) > Thanks, we'll fix. Luigi > > Yours, > Joel M. Halpern _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
