Spencer Dawkins has entered the following ballot position for draft-ietf-lisp-impact-04: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-impact/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "RLOC" is spelled out on second use, but not on first use. "Addresses are semantically separated in two:" was a bit rough for me. Perhaps something like "Addresses have two components with different semantic meanings:"? In this text: Middle boxes/filters: because of encapsulation, the middle boxes may not understand the traffic, which can cause a firewall to drop legitimate packets. In addition, LISP allows triangular or even rectangular routing, so it is difficult to maintain a correct state even if the middle box understands LISP. Finally, filtering may also have problems because they may think only one host is generating the traffic (the ITR), as long as it is not de-encapsulated. To deal with LISP encapsulation, LISP aware firewalls that inspect inner LISP packets are proposed [lispfirewall]. I wonder if we're far enough along with RFC 7258/BCP 188 that we expect middleboxes may not understand traffic, whether it's encapsulated or not, because of encryption. Perhaps that's worth a thought, if not a mention. _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
