Now with LISP on the To: line On Thu, Feb 7, 2019 at 5:37 AM Eric Rescorla <[email protected]> wrote:
> I apologize for the length of this e-mail, but there's a lot to > go over. > > I have gone over the responses to my DISCUSS on the LISP > documents as well as taken another look at LISP-SEC. I agree that a number > of the > issues I raised are resolved, and I note those below. However, > I believe that a number of issues remain. > > First, as a procedural I do not think it's appropriate to approve two > documents (6830bis and 6833bis) which have critical security > dependencies on documents (LISP-SEC, Map-Version) which are not yet > before the IESG and therefore have contents which might change during > IETF-LC. I'll happily re-review all these documents together. > Alternately, you can precisely state the properties of LISP-SEC > that you are depending on and we can review these documents > assuming those are correct and then subsequently review > LISP-SEC against that standard. > > Second, LISP-SEC is MTI, not MTU, but that means that we need > to evaluate the security properties of LISP in the case where > LISP-SEC is not in use; I do not believe those properties are > appropriate for a new Internet protocol, as they do not provide > reasonable security against integrity attacks. Is there a reason > that comsec is not mandatory in this case? Note the text > in RFC 3552 which says: > > Note: In general, the IESG will not approve standards track protocols > which do not provide for strong authentication, either internal to > the protocol or through tight binding to a lower layer security > protocol. > > Additionally (and this is dicta because LISP-SEC is not before > us), the design of LISP-SEC seems unnecessarily complicated and > brittle, so at some point that's worth examining. > > Moving to the DISCUSS-worthy points I raised in my review (ignoring > non-blocking comments for now). > > > RFC 6833bis > > THREAT MODEL > > I'm assuming the usual RFC 3552 threat model, I.e., > > > > - All non-Map Server elements in the system (specifically, endpoints > > and the xTRs are potentially malicious). > > > > - Aside from the links between the Map Server elements, the network > > is controlled by the attacker. > > > > Against this background, my expectation is that the attacker > > should not be able to affect traffic in any fashion significantly > > more effective than tampering with the data plane. For instance, > > it's clearly the case that an on-path attacker between two xTRs > > can drop all the packets or forward them to some third xTR, but > > it should not be able to send a small number of packets which > > would then affect the routing of a large number of packets. > > > > I do not expect that the data plane should have better security > > than native (non-IPsec) traffic. Given the nature of LISP and > > the existence of a mapping system, it seems like it's kind of > > a missed opportunity to deploy a credentials system that would > > support IPsec-style data plane security, but given that this > > isn't a generally safe assumption for IP traffic, and therefore > > you need to provide some sort of transport or application security > > anyway, I don't think it's the right standard to hold LISP to. > > This is preface. > > > > ATTACKS > > LISP appears to be vulnerable to a number of routing attacks that > > I claim above it should not be subject to. For example: > > > > 1. An on-path attacker can forge Map Replys to the ITR, > > thus redirecting traffic. > > > > 2. An ETR can perform an "overclaiming" attack in which it > > claims to be responsible for EIDs which it is not actually > > responsible for. > > I believe that both of these are intended to be protected against > by LISP-SEC, but LISP-SEC is not MTU. > > > > 3. An off-path attacker can temporarily reroute traffic by exploiting > > the "gleaning" feature to cache poison an ITR. In addition, the > > "echo noncing" feature does not appear to have a sufficiently strong > > nonce to protect against forgery, and thus turning this into a > > long-term attack > > > > 4. An attacker may be able to perform a number of cache invalidation > > and contamination attacks by exploiting the Map-Version and > > Locator-Status bits. This may lead to DoS. > > In the spreadsheet, you say that this is addressed in the 6833-bis > security considerations, but I don't see it. In any case, I don't > understand why it cannot be fixed, rather than just documented. > > > > 5. An attacker who was at time T responsible for an EID block > > can probably prolong its ability to respond for that block > > even after it is no longer responsible. > > I agree that this is addressed. > > > > 6. A number of the components appear to be subject to various replay > > attacks. > > As above, I don't believe that this is fixed. > > > > DEFENSES > > When looking at attacks, it's important to determine whether there are > > plausible defenses. For most of these, I believe that the answer is > > "yes", at varying levels of cost. As noted above, LISP-SEC appears to > > be intended to address a number of these issues, so it's possible that > > requiring LISP-SEC would go a fair ways towards addressing these > > issues. A cursory look at LISP-SEC turns up some somewhat concerning > > design choices, so I would have to examine it more closely to give a > > real opinion. > > > > I do not believe that LISP-SEC will address the attacks that do not > > involve the Mapping Server. For instance, the gleaning > > contamination/nonce attacks (3) would not appear to be fixed by > > LISP-SEC. However, it's probably possible to fix them by lengthening > > the nonce. > > It's not clear to me that these are documented, but even if they > are, they should be fixed or at least we need an explanation of > why they can't be. The nonce one is especially obvious as it > seems to be just a case of making it bigger. Relying on uBPRF > does not seem sufficient. > > > > With that said, I tend to think that the overall authentication > > architecture here would benefit from a rethink. At a high level, the > > source of most of these problems is the "non-transferability" of the > > mapping information from the Map Server. If the Map Server instead had > > an asymmetric key pair which it used to sign mappings, then almost all > > of these attacks would not work. Specifically: > > > > - The map server could send signed Map Replys so forgery wouldn't work > > > > - Map Replys from ETRs would be signed, so you couldn't overclaim > > > > - Gleaning attacks would sort of work, but because the probe would > > elicit a Map Reply, you couldn't persist them > > > > - Map Versions could be tied to signed objects, so you couldn't do > > cache invalidation by version. You'd probably need some other > > approach for Locator Status bits. > > > > And so on. > > You say that there is text about this in security considerations, > but it mostly seems to just restate the current design, not explain > why a better one is not possible. > > > IMPORTANT > > S 5.2. > > > s: This is the SMR-invoked bit. This bit is set to 1 when an xTR > is > > > sending a Map-Request in response to a received SMR-based Map- > > > Request. > > > > > > m: This is the LISP mobile-node m-bit. This bit is set by xTRs > that > > > operate as a mobile node as defined in [I-D.ietf-lisp-mn]. > > > > This would appear to create a normative reference to this document. To > > avoid that, you need to specify how I behave if I receive it but I > > don't implement lisp-mn. > > I agree that this is fixed. > > > > S 5.2. > > > m: This is the LISP mobile-node m-bit. This bit is set by xTRs > that > > > operate as a mobile node as defined in [I-D.ietf-lisp-mn]. > > > > > > I: This is the xTR-ID bit. When this bit is set, what is > appended to > > > the Map-Request is a 128-bit xTR router-ID. See LISP PubSub > usage > > > procedures in [I-D.ietf-lisp-pubsub] for details. > > > > here too you seem to be creating a normative reference. > > This as well. > > > > S 5.5. > > > is being mapped from a multicast destination EID. > > > > > > 5.5. EID-to-RLOC UDP Map-Reply Message > > > > > > A Map-Reply returns an EID-Prefix with a prefix length that is > less > > > than or equal to the EID being requested. The EID being > requested is > > > > How do I behave if I receive an EID-Prefix that is less than any of my > > mappings. So, I might have mappings for 10.1.0.0/16 and 10.2.0.0/16 > > and someone asks me for 10.0.0.0/8? Also, when you talk about prefix > > length, I assume you mean the length fo the mask? > > We had an extended back and forth on this. I still don't find the document > very clear, and I'm not sure that this text is correct. Specifically, > consider the following example, where the MS has two mappings: > > 10/8 -> ETR1 > 10.0.1/24 -> ETR2 > > The Map-Request is for 10.1/16. In email, we agreed that you cannot return > only the first mapping because that would implicitly over-claim. This means > that you either supset one of your mappings or return both (I understood > Dino to be saying you return both). However, the 10.0.1/24 mapping has > a longer prefix than the requested one, so that would seem to violate this > text. > > > > S 5.6. > > > Authentication Data: This is the message digest used from the > output > > > of the MAC algorithm. The entire Map-Register payload is > > > authenticated with this field preset to 0. After the MAC is > > > computed, it is placed in this field. Implementations of this > > > specification MUST include support for HMAC-SHA-1-96 [RFC2404], > > > and support for HMAC-SHA-256-128 [RFC4868] is RECOMMENDED. > > > > What prevents replay attacks here? I'm guessing it's the Map-Version- > > Number, but as I understand it, I can set this to 0. > > You write in your spreadsheet: > "We have fixed this, now Map-Register have an incremental nonce to > prevent replay attacks (in 6833bis: "Nonce: This 8-octet 'Nonce' field > is incremented each time a Map-Register message is sent") " > > It's not clear to me why this prevents replay. Can you please walk me > through the mechanism? > > > > > > S 6.1. > > > receives an SMR-based Map-Request and the source is not in the > > > Locator-Set for the stored Map-Cache entry, then the responding > Map- > > > Request MUST be sent with an EID destination to the mapping > database > > > system. Since the mapping database system is a more secure way to > > > reach an authoritative ETR, it will deliver the Map-Request to the > > > authoritative source of the mapping data. > > > > If I'm understanding this correctly, this allows an ETR to prevent an > > ITR from learning that it is no longer the appropriate ETR for a > > prefix. The way this attack works is that before the topology shift, I > > send SMRs, thus causing Map-Requests, which, because my entry is > > cached, refresh the cache on the ITR past the topology shift. I can > > keep doing this indefinitely. Am I missing something > > I agree with your response here and consider this resolved. > > > > > S 8.2. > > > authentication data, so prior to sending a Map-Register message, > the > > > ETR and Map-Server SHOULD be configured with a shared secret or > other > > > relevant authentication information. A Map-Server's configuration > > > SHOULD also include a list of the EID-Prefixes for which each ETR > is > > > authoritative. Upon receipt of a Map-Register from an ETR, a Map- > > > Server accepts only EID-Prefixes that are configured for that ETR. > > > > How does it know? > > This now seems to be clear. > > > > COMMENTS > > S 5. > > > \ | UDP Length | UDP > Checksum | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > | | > > > | LISP > Message | > > > > | | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > What do these two diagrams correspond to? v4 and v6? This needs > > explanation. > > This seems to be resolved. > > > RFC 6830 bis > > DETAIL > > S 4.1. > > > RLOC (outer-header source IP address) in a received LISP > packet. > > > Such a cache entry is termed a "glean mapping" and only > contains > > > a single RLOC for the EID in question. More complete > information > > > about additional RLOCs SHOULD be verified by sending a LISP > Map- > > > Request for that EID. Both the ITR and the ETR MAY also > > > influence the decision the other makes in selecting an RLOC. > > > > This seems like it introduces an immediate overclaiming problem. > > I seem to have misunderstood this. > > > > S 10. > > > When an ETR decapsulates a packet, it will check for any change in > > > the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the > > > ETR, if acting also as an ITR, will refrain from encapsulating > > > packets to an RLOC that is indicated as down. It will only resume > > > using that RLOC if the corresponding Locator-Status-Bit returns > to a > > > value of 1. Locator-Status-Bits are associated with a Locator-Set > > > > This seems to enable a pretty obvious denial of service attack in > > which you send a message with all LSBs set to 0. > > The change here seems to be: > > " An ETR MUST rate-limit the action it takes when it detects changes in > the > Locator-Status-Bits." > > I'm not sure I understand what this text means, but in any case it > doesn't seem to address the concern I had, which was the use of > LSB=0 to empty the cache. It's not clear why rate limiting helps > that. > > > > > S 10. > > > list returned by the last Map-Reply will be set to zero for that > > > particular EID-Prefix. Refer to Section 16 for security related > > > issues regarding Locator-Status-Bits. > > > > > > When an ETR decapsulates a packet, it knows that it is reachable > from > > > the encapsulating ITR because that is how the packet arrived. In > > > > It doesn't even know this. It just knows that that's been claimed by > > someone who can generate traffic to it. > > This was mostly about clarity. > > > > S 10.1. > > > NOT use the lack of return traffic as an indication that the ETR > is > > > unreachable. Instead, it MUST use an alternate mechanism to > > > determine reachability. > > > > > > 10.1. Echo Nonce Algorithm > > > > > > > This mechanism seems sufficient to verify unreachability but is not a > > secure test of reachability because the nonce is way too short. > > Your response (as above) is that you updated security considerations, > to document this, but why not simply fix it? > > > > S 16. > > > Map-Versioning is a Data-Plane mechanism used to signal a peering > xTR > > > that a local EID-to-RLOC mapping has been updated, so that the > > > peering xTR uses LISP Control-Plane signaling message to retrieve > a > > > fresh mapping. This can be used by an attacker to forge the map- > > > versioning field of a LISP encapsulated header and force an > excessive > > > amount of signaling between xTRs that may overload them. > > > > Can't I also set a super-high version number, thus gagging updates? > > You say "This attack is discussed in the Security Section of 6830bis." > > The relevant text says: > > Map-Versioning is a Data-Plane mechanism used to signal a peering xTR > that a local EID-to-RLOC mapping has been updated, so that the > peering xTR uses LISP Control-Plane signaling message to retrieve a > fresh mapping. This can be used by an attacker to forge the map- > versioning field of a LISP encapsulated header and force an excessive > amount of signaling between xTRs that may overload them. > > A thorough analysis of this depends on Map-Versioning, which, as above, > is not in scope here, but why can't this be fixed? > > >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
