[RAM] ETRs checking src & dest addresses

[Robin Whittle <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ram