Re: [RAM] ITR complexity & security (ICMP) in LISP-NERD/CONS & eFIT-APT

Hi Noel,

Thanks for your response.

In this reply, I discovered what I think are two nasty problems
with what I have written so far about "outer SA = inner SA"
enabling the sending host to discover reachability and to do Path
MTU Discovery, without involving the ITR.

I have pointed to this message from:

  http://www.firstpr.com.au/ip/ivip/to-do/

because of these problems.

You wrote:

> All ITRs/ETRs have their interfaces which face toward the 'core' (i.e. the
> other ITRs/ETRs in the system) have addresses from some reserved part of the
> address space (e.g. net 10), addresses which are not functional on the 'site'
> side of the ITRs/ETRs. (I.e. you can't send a packet to one of the addresses
> from inside a site.) The ITRs only accept reachability DU messages on those
> interfaces, destined to the addresses from the reserved space.
> 
> In other words, there's no way to send them one of these DU packets from a
> customer site. This should be easier than carefully validating each
> individual DU, and keeping enough state to do so, right?
> 
> Yes, this still allows a compromised ITR/ETR to generate bogus traffic, but I
> think it's a useful reduction in the threat universe.

I think that eFIT-APT is intended to ultimately result in
something like this complete separation of core addresses from
provider network internal addresses.  There isn't any particular
address space for the core - it could be just some bunch of
prefixes, as far as I know - but once it was fixed, the routers
could all be programmed to not allow packets from non-core
addresses to core addresses.

However, this can only be fully achieved, to my understanding,
once every network is upgraded to the new system.  As long as it
is necessary to accept packets from non-upgraded networks, there
is no complete fence around the "core".  Even if there was, I
think this is a "strength of the weakest link in a chain" approach
to security, where one leak can sink the boat - to combine two
well-used metaphors.

I try to discuss this vision of eFIT-APT, which is my own - not
that of the authors - in the "Incremental deployability" section of:

  http://www.firstpr.com.au/ip/ivip/comp/

I think the "core separation by address range" solution as you
suggest would be hard or impossible to incrementally deploy.

> I don't have any clearest best idea on how to validate incoming DU messages
> from other ITRs/ETRs... Maybe a per-ETR nonce (i.e. only a slight amount of
> increase in the state in the ITR), which is included in each tunnelled
> packet, or something like that. If it's 32 bits, and changed every 10
> seconds, it would be hard to find by generating random values (and in any
> case the incoming errors could set off alarm bells), and even if it were
> found, it would only give you a break-in for a few seconds.

I don't see a totally rock-solid cryptographic way of doing it
with UDP encapsulation, since as far as I know, the ICMP DU
message is only required to return the IP header and the following
8 bytes, which is the UDP header.

I think that by randomising the UDP port number the encapsulated
packet is sent from, the ITR could make it hard for an attacker to
stumble upon the right 16 bits of port and the right 16 bits of
checksum, even if they could guess the length, which I figure they
could pretty easily.  That is getting close to 32 bits of
crypto-like hard-to-find difficulty.  Also, the attacker has to
get it right for a packet sent in the last second or so - so I
think this combination of two 16 bits of variability would be
pretty solid.

A workaround for marginally sub-optimal security would be for the
ITR to not take drastic action due to a single ICMP DU message -
which seems prudent anyway.

> In short, I agree this is a problem, and one that needs a solution, but
> I'm not sure the mechanism you posit is the best solution.
> 
> In part, you seem to be trying to solve it without changing the protocol
> (i.e. packet format), and I think that's too hard a constraint. If you really
> need a screwdriver, go buy one, don't try and make do with a hammer.

The only reason I am going to all this trouble describing the
problem and the difficulty of solving it is to suggest that the
whole approach of having the ITR tunnel packets with the outer
header Source Address (SA) being its own ITR address, is wrong.

I know this is the conventional way to do it, but when I designed
Ivip, I copied what I thought LISP was doing, wrongly thinking
that it sent the packet with the outer SA = the sending host's
address.

I think that this "outer SA = inner SA" turns out to have three
major benefits (actually maybe two are duds . . . ), including:

1 - The ITR never gets ICMP DU packets for unreachability - those
    which are generated in the tunneled part of the packet's
    journey will go straight to the sending host.

    (This cannot be contemplated for LISP or eFIT-APT - unless
    the ITR sends probe packets and does reachability by getting
    a positive response from any ETR which is really reachable.
    As far as I know, it is a central tenet of LISP and eFIT-APT
    that the database updates are slow so the ITRs need to test
    for reachability themselves and make their own real-time
    decisions about multihoming service restoration at the time
    they are tunneling traffic.)

    !! Unfortunately, this may not work for reasons explained in
    !! the next point . . .

    Anyway, relying on ICMP is a lousy approach for any host
    testing for reachability.  It is not reliable anyway, in part
    due to filtering of ICMP messages to reduce security problems.

2 - The ITR never gets ICMP DU packets which result from
    the sending host's attempt to discover the MTU of the path
    to its destination host, and where the encapsulated packet
    is too big for some router.  The ICMP packet goes back to
    the sending host . . .

    Hmmm, unfortunately, the sending host might not recognise it,
    because it carries with it a copy of the ITR's outer packet
    and 8 bytes of whatever comes next (IP header for Ivip's
    current IP-in-IP encapsulation, or alternatively the UDP
    header for UDP encapsulation).  This does not resemble
    the IP header and next 8 bytes of the packet the sending host
    sent - so it should ignore it.

    !! I just realised this - PMTUD probably *won't* work  ~:(

    PMTUD is unreliable anyway.  Still I think the new
    architecture should not degrade or worse still completely
    break it.

    Since the new architecture involves tunneling, there are
    going to be pervasive MTU problems leading to fragmentation.
    Maybe while designing a new architecture, there needs to be a
    fresh approach to PMTUD anyway - which will probably involve
    changes to host operating systems.  But without it, there are
    going to have to be some changes to hosts, ideally automatic
    via different DHCP values, so hosts generally send packets
    which are short enough that when encapsulated they generally
    won't be fragmented.  (This is an IPv4-centric discussion.)

3 - I think it makes it much easier for the ETR to enforce the
    border routers filtering to stop an attacker from outside the
    network sending packets which when decapsulated contain
    sending addresses from the network's own prefixes.

    I wrote a lot about this on 14 July:

    http://www1.ietf.org/mail-archive/web/ram/current/msg01705.html

 - Robin

_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram