[RAM] ETRs checking src & dest addresses
Robin Whittle <rw@firstpr.com.au> Thu, 12 July 2007 11:55 UTC
Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8xGN-0000AE-9R; Thu, 12 Jul 2007 07:55:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8xGA-0008Jo-RZ for ram@iab.org; Thu, 12 Jul 2007 07:55:02 -0400
Received: from gair.firstpr.com.au ([150.101.162.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8xDL-0007yO-6x for ram@iab.org; Thu, 12 Jul 2007 07:52:12 -0400
Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 9DB1359E3D; Thu, 12 Jul 2007 21:52:03 +1000 (EST)
Message-ID: <469615D5.4010408@firstpr.com.au>
Date: Thu, 12 Jul 2007 21:51:49 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: ram@iab.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213
Subject: [RAM] ETRs checking src & dest addresses
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org
I think ETRs will require careful management to stop them being used by attackers to get around existing filtering systems. I will use the terms "inner packet" to refer to the packet which is encapsulated and "outer packet" to refer to the whole thing, with encapsulation. On a border router - the one accepting packets from BGP peers - is there sometimes or often a filter to drop packets whose SA matches any of network's own the prefixes? I guess most well-run networks do this. If so, maybe all ETRs need to do the same regarding the SA of the inner packet - unless the ETR can be sure the outer packet packet was sent from an ITR within the local network. In the current definition of Ivip, the SA of the outer packet is the same as of the inner packet - it is the address of the original sending host, not of the ITR. Maybe there is a reason for using the ITR's address for the outer SA, but for now I will assume not. If the network's border routers filter packets coming from the rest of the Internet to reject those with SA matching local prefixes, then all the ETR has to do to enforce the rule of not forwarding inner packets from outside the network with a spoofed local address, is to drop any inner packet which has a different SA from the outer SA. The simplicity of this arrangement is probably a good argument for retaining the current definition that the ITR uses the original packet's SA for the SA of the outer IP header. If the network's border routers don't have such filters, then it probably doesn't matter much whether the ETR is fussy about the inner SA, since the whole system is insecure anyway. Ideally, the ETR would be a lot fussier than just dropping an inner packet if its inner SA doesn't match its outer SA. Ideally it would drop any inner packet with an SA which did not match a narrow range of addresses: the LISP EID or Ivip DID (endpoint identifier) addresses of hosts or routers which it has been configured to decapsulate packets for. That set would depend on whether it could only send the decapsulated packets to end-user hosts or routers with direct connections to this ETR (or via some tunnel to wherever in the local network they can be reached) or whether the local routing system had specific routes for all the Ivip-mapped addresses of such end-user hosts and routers. In the latter case, the ETR should forward all decapsulated packets which match any of the Ivip-mapped hosts in the network. If there was no restriction on the inner DA of packets an ETR forwards, then an attacker could send an outer packet to an ETR in network A, with the inner packet being forwarded out of this network to some other host in another network B, including via an ITR if the inner DA was an Ivip-mapped address. Actually, if ETRs simply decapsulated and forwarded every packet they got, an attacker could create a nested set of IP-in-IP headers so the packet was decapsulated, forwarded to another ETR - even the same ETR . . . - and decapsulated again, to go to another ETR and so on. Also, the inner packet from an attacker could have an Ivip-mapped address which was not a host in the current network with that Ivip-mapped address, so the packet would find its way to an ITR and be forwarded somewhere, presumably to an ETR in some other network, where it would be decapsulated to reveal yet another packet which gets forwarded somewhere. If there were lots of ETRs around which were not fussy enough about the DA of inner packets, then I can imagine this becoming a sport: a Russian Doll game of leapfrogging around the ETRs and potentially the ITRs of the world! The object would be to launch a packet into some ETR (in a network which doesn't implement the drop rules I suggest below) and have as many levels of inner packet as packet length allows, with the first inner packet being an IP-in-IP header which is addressed to another ETR, which decapsulated it to create another packet which goes to some other ETR and is decapsulated etc. Finally, the innermost packet would arrive back at the player's computer, after having been forwarded, smaller and smaller, each time, between different ETRs and maybe ITRs all over the Net for the last few seconds. Below my signature is how I worked out the following rules, assuming that the ETR always drops a packet which has a different inner SA from its outer SA: Irrespective of whether the network filters incoming packets to reject those with source addresses which are within local prefixes, and: Irrespective of whether there are any ITRs (ITRDs, ITRCs or ITFHs) in the local network (and ITFHs could be hard to spot or prevent): If the local routing system supports forwarding of the specific Ivip-mapped addresses which are currently used by hosts with such addresses, meaning it forwards the raw packets to the proper host (or a link to an end-user site where they have a router etc.) then: Forward the inner packet only if it matches that list of hosts, end-user networks etc. which are in this network. Alternatively, if the local routing system doesn't have special routes for these Ivip-mapped addresses, then: Forward the inner packet only if it matches that list of hosts, end-user networks etc. which are directly connected to this ETR (or reachable via some tunnel). - Robin Here is an attempt to be systematic about this. I will ignore private (non globally routed) addresses. Most of this would apply to LISP as well, I think, but I will only mention Ivip. Addresses are: Local = within a prefix this network advertises to BGP. Non-Local = any other address, which includes all IMIP addresses: IMIP = Ivip-mapped address: within one of the Ivip Mapped Address Blocks (IMABs). Loc-DID = This will be within the IMIP set (and therefore also within the non-local set) but matches one of the addresses of hosts in the local network with Ivip-mapped addresses. Dir-DID = An address within the one or more Ivip-mapped addresses for hosts or routers which this ETR has a direct connection with. These are a subset of Loc-DID. In the current definition of Ivip encapsulated packet, the outer SA is the same as the inner SA. Any packet arriving with a different outer SA than inner SA probably should be dropped, because it doesn't comply with Ivip - so the following assumes they are the same. The outer DA is the address of the ETR, otherwise the packet wouldn't be here. The questions are the way the network is organised and what classes the outer/inner SA and the inner DA fall into. 111 --- Border router drops packets arriving from BGP peers with SA = Local? Yes Internal routing system recognises Loc-DID addresses with special routes to the appropriate host? Yes Some ITRDs, ITRCs or ITFHs in local network may encapsulate legitimate packets? Yes Outer SA Inner DA ETR should: =Inner SA Any Loc-DID Decapsulate and forward. If the SA is Local, it is valid, because packets from outside with AS = Local (a spoofed source address) have been blocked by the border router. So if SA is local, this must have been via a local ITR. Any Not Loc-ID Drop - must be an attacker trying to get past filters to send packet to an ordinary non-Ivip-mapped host in the local network or to some other host (on a normal or an Ivip-mapped address) in another network - which is not what Ivip and this ETR are for. 110 --- This differs from 111 only in that: Border router drops packets arriving from BGP peers with SA = Local? No The actions of the ETR are the same, although the reasons are not: Any Loc-DID Decapsulate and forward. If the SA is Local, it could be a spoofed packet, but there is no reason to drop it because the network admins don't care enough about spoofed SAs to filter them out at the border router. Any Not Loc-ID Drop - must be an attacker - see 111. 10x --- Border router drops packets arriving from BGP peers with SA = Local? F = Yes or No Internal routing system recognises Loc-DID addresses with special routes to the appropriate host? No Some ITRDs, ITRCs or ITFHs in local network may encapsulate legitimate packets? Yes Outer SA Inner DA ETR should: =Inner SA Any Dir-ID Decapsulate and forward. See 110 and 111 for reasons why whether F = Yes or No. Any Not Dir-ID Drop - ETR only knows how to get packets to directly connected hosts/routers with Ivip-mapped addresses. 01x --- Border router drops packets arriving from BGP peers with SA = Local? F = Yes or No Internal routing system recognises Loc-DID addresses with special routes to the appropriate host? Yes Some ITRDs, ITRCs or ITFHs in local network may encapsulate legitimate packets? No Outer SA Inner DA ETR should: =Inner SA Non-Local Loc-ID Decapsulate and forward. See 110 and 111 for reasons why whether F = Yes or No. Local Loc-ID F = Yes: Why does this happen? No local ITRs and filters mean this couldn't have come from outside. F = No: Decapsulate and forward - its probably from an attacker but the admins don't care. Any Not Loc-ID Drop - must be an attacker - see 111. 00x --- This is the same as 01x, except that the test is for Dir-DID instead of Loc-DID. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram
- [RAM] ETRs checking src & dest addresses Robin Whittle
- Re: [RAM] ETRs checking src & dest addresses Iljitsch van Beijnum
- Re: [RAM] ETRs checking src & dest addresses Robin Whittle