Subject: [tcpm] comments on draft-ietf-tcpm-tcp-antispoof-02

From: Pekka Savola <[email-masked]>
Date: Sun, 6 Nov 2005 20:01:14 +0200 (EET)

My comments below.  There are still some things to fix, but most of 
the below should be straightforward.

substantial
-----------

1) the receiver buffer sizing assumption does not seem realistic in
sufficiently many cases so that I think it should not be made.

    3. the advertised receive window is a large fraction of the overall
       maximum receive window size, e.g., because the receive socket
       buffers are set to match a large bandwidth-delay product

[...]
    Of these assumptions, the last two are more notable.  The issue of
    receive socket buffers was discussed in Sec. 2. [....]

==> the receive buffer assumption rattled me a bit, especially in the
context of BGP.  I think it's very common, especially when talking about
routers, that a single application does not expect to use all the bandwidth
of the link.  It usually even can't: the route processors are busy with
other stuff, and might be very slow.  A BGP session which would fly at the
rate of (even) 100 Mbit/s would be a surprise to me.

I just checked; Cisco has by default around 4 KB for BGP (for others, 32KB),
and it isn't even possible to config it up to more than 128K.  Juniper
has by default 16KB, and AFAICS there is no way to configure it.

Given that the document talks so much of the specific case of BGP sessions,
it seems that the document shouldn't just go ahead with an assumption that's
known to be wrong in that (and many other cases).  I don't think changes the
main thrust of the document, though: attacking the sessions would still be
achievable in the order of seconds or a minute.  Maybe what needs to be done
is calculate two tables: one where the buffers are adjusted so that the
bandwidth can be used in a maximum manner and where the buffers are capped
at (say) 16, 32 or 64 kB. 
That would give realistic calculations in either case without having to
make assumptions about the buffers.

(This same is in the first sentence of section 3.1.5.)

2) I think the address filtering (section 3.2.1) is still a bit lacking. 
Its main problems are:

  a) "It cannot restrict traffic from the core to the edges" -- but it can,
assuming you mean an independent leaf-site with "edge" here.  Specifically,
all sites should and must perform filtering of their own, to discard any
packets which come with their own source address from the direction of the
Internet.  This eliminates spoofing attacks from outside of the border.
(This seems to be correctly reflected in the subsequent text, so maybe I
just didn't understand what you meant with the above statement.)

  b) TTL checking problem with tunnels is still inaccurate.  Tunnel is like
any other (physical interface).  If you get packets from an interface that
are directed at you, the TTL is not decremented; if you forward those
packets on some other interface, the TTL is decremented.  Therefore the case
where the TTL checking would be too unreliable is the same whether the
neighbor peer has virtual or physical interfaces: if your peer doesn't
behave properly (decrement the TTL), it's de-facto masquerading as someone
else.  The TTL check specifically assumes that you are able to trust your
peer not to rewrite or create bogus packets, there is very little
tunneling-specific about this as far as I can see.

  c) At the beginning of section 3.2, you say "filtering is an indirect
system which relies on other parties to filter packets ..." which is
correct in the general case but not when examining the sessions inside a
border (where you can _yourself_ do the filtering, without relying on anyone
else).  This distinction is important depending on what kind of sessions
you're interested in protecting and how large area your borders cover.

...  In order to try to converge on the text faster, let me try to suggest
text which I think should be more accurate and I'd find acceptable.

================
3.2. Network Layer (IP) Solutions

    There are two primary variants of network layer solutions to
    spoofing: address filtering and IPsec. Address filtering provides
    protection from spoofing for sessions which are internal to the set
    of domains where address filtering is applied.  IPsec requires
    cooperation between the
    endpoints wanting to avoid attack on their connection, which
    currently involves pre-existing shared knowledge of either a shared
    key or shared certificate authority.

3.2.1. Address and TTL filtering

    Address filtering is often proposed as an alternative to protocol
    mechanisms to defeat IP source address spoofing [2][12].

    Address filtering is deployed both at the downstream interfaces and at
    the upstream/peer interfaces.  The former prevents all spoofing from the
    downstream direction; the latter prevents only upstream sources from
    spoofing your (or your downstreams') source addresses.
    Each border router should perform the appropriate filtering for overall
    protection to result; failure of any border router to filter opens a
    hole inside that border.

    Address filtering at the border can protect those inside it
    from some kinds of spoofing, because only interior addresses should
    originate inside the border. It cannot, however, protect connections
    originating outside the border except to restrict where the traffic
    enters from, e.g., if it expected from one AS and not another.

    As a result, address filtering can be deployed locally but it only
    protects communications where both parties are local.  Therefore, the
    larger the address filtering border is, the more extensive the protection
    is.  This is a particularly useful means of protection for specific kinds
    of sessions which are known to be local.  However, as address filtering
    is performed in the network by trusted gateways, the users not know
    whether the filtering exists or not.  Hence, the users cannot rely on it
    in general and other mechanisms for protection must be used as well.
    Still, address filtering is very useful to protect specific kinds of
    communications (e.g., network management, most router-to-router
    communication, etc.).

    A more recent variant of address filtering checks the IP TTL field,
    relying on the TTL set by the other end of the connection [14]. This
    technique has been used to provide filtering for BGP. It assumes the
    connection source TTL is set to 255; packets at the receiver are
    checked for TTL=255, and others are dropped. This restricts traffic
    to one hop upstream of the receiver (i.e., a BGP router), but those
    hops could include other user programs at those nodes (e.g., the BGP
    router's peer).

    This method of filtering works best where traffic originates one hop
    away, so that the address filtering is based on the trust of only
    directly-connected (tunneled or otherwise) nodes. Like conventional
    address filtering, this light-weight mechanism reduces spoofing
    traffic in general and provides a reliable security mechanism if peer
    can be trusted to operate correctly (see Section 5.1 of [14]).  On the
    other hand, if the peer does not operate correctly, it is just shooting
    itself in the foot by allowing its sessios to be reset.
================

..............

3) the processing complexity comparison between transport vs network 
solutions seems assumptive.

[issues why transport layer solution is not good]
         Finally, because the
    authentication happens later in packet processing than is required,
    additional endpoint resources may be needlessly consumed, e.g., in
    demultiplexing received packets, indexing connection identifiers,
    etc., only to be dropped later at the transport layer.

and:

    A network layer solution avoids the hazards of multiple transport
    variants, using a single shared endpoint authentication mechanism
    early in receiver packet processing to discard unauthenticated
    packets at the network layer instead.

==> a reality check might be useful here.  What is computationally more
expensive -- demuxing and checking the transport control packets or doing
IPsec processing and decryption (and dropping a packet when it fails the
IPsec transform)?  Unless you have IPsec hardware, the answer should be
pretty obvious...  (obviously, the address filtering mechanisms are still
computationally more lightweight than either of these.)

4) network layer solution may not be able to cope with on-path ICMP.

Finally, a network layer solution
    protects not only the transport layer but the network layer as well,
    e.g., from ICMP, IGMP, etc., spoofing attacks.

==> this appears to be too simplistic a statement.  You are probably
assuming that ICMP errors from the path can be safely ignored.  If they
can't, network mechanisms like IPsec cannot in practice cope with this kind
of packets because setting up SAs to all the middleboxes is not
feasible.

5) BTNS applicability is slightly too simplistic

    Alternative mechanisms are under development to address this
    limitation, to allow publicly-accessible servers to secure
    connections to clients not known in advance, or to allow unilateral
    relaxation of identity validation so that the remaining protections
    of IPsec to be available [38][39]. In particular, these mechanisms
    can prevent a client (but without knowing who that client is) from
    being affected by spoofing from other clients, even when the
    attackers are on the communications path.

==> AFAICS, "are on the communications path" is assumptive or simplistic.
Either you must
have a previously established relation (which you know is MITM-free) to
a peer, or you meant something like "would later, after establishing
the session, get on the communications path".  After all, BTNS does not
protect from MITM if the MITM was there when the session was set up and
you don't have prior knowledge of the peer.

6) The description why IPsec is not used to protect router-to-router 
communications fails to address the added IPsec processing 
requirements, which are typically prohibitive.

    IPsec, although widely available both in commercial routers and
    commodity end-systems, is not often utilized except between parties
    that already have a preexisting relationship (employee/employer,
    between two ISPs, etc.) Servers to anonymous clients (e.g., customer/
    business) or more open services (e.g., BGP, where routers may have
    large numbers of peers) are unmanageable, due to the breadth and flux
    of CAs. [...]

==> This is too simplistic description of why IPsec isn't used between
routers.  While management of certificates is a major issue, at least as
important for me as an operator are the processing requirements of
IPsec.  If you don't have dedicated hardware for the task, I'd rather spend
the routing engine's CPU cycles on processing the BGP update packets (and
other control data) rather than encryption, decryption, hashing, etc.

Let me say this clearly: BTNS/Anonsec will not be used by routers unless
they have dedicated IPsec hardware (and the vast majority of them won't in
the short term at least).  (Hopefully this will be appropriately 
reflected in the  BTNS problem statement as well.)

7) not sure if I agree with conclusions because we haven't yet 
reached consensus on the body yet (this is a placeholder :)

    The security of various levels of the protocol stack is addressed.
    Spoofing attacks are fundamentally identity masquerading, so we
    believe the most appropriate solutions defeat these at the network
    layer, where end-to-end identity lies.  Some transport protocols
    subsume endpoint identity information from the network layer (e.g.,
    TCP pseudo-headers), whereas others establish per-connection identity
    based on exchanged nonces (e.g., SCTP).  It is reasonable, if not
    recommended, to address security at all layers of the protocol stack.

==> not sure if I completely agree with these conclusions here (and
in section 5), but when/if we get to agreement on the main body of the
doc, it should be easier to get to consensus on the recommendations as well.

editorial
---------

    This, coupled with the lack of sufficient address filtering to drop
    such spoofed traffic, can increase the potential for off-path third-
    party spoofing attacks.

==> you include refs later in the doc for this, so maybe they should be
here as well.

    [...] even when not
    fixed, there are only 65,384 valid source ports which may be
    exhaustively attacked.

==> how do you get that specific number?  Why this isn't 2^16 ?

    protocol, although emerging as standard practice, unnecessarily
    complicates the design and implementation of new protocols [28]  As
    new attacks are discovered (SYN floods, RSTs, etc.), each protocol

==> missing a period here.

   In addition, many networks filter all ICMP packets because validation
    may not be possible, especially because they can be injected from any
    point on a path, and so cannot be selectively address filtered.

==> actually, the problem with ICMP is that they can be injected from any
point *at all*, not just restricted to the path, and regular address
filtering doesn't help there (whereas address filtering could help with TCP
RSTs in some cases).

    Network solutions are computationally intensive and require pervasive
    registration of certificate authorities with every possible endpoint.
    This section explains these observations further.

==> after the addition of address filtering in section 3.2, this needs to be
updated to refer to just the ipsec part of network solutions.

    4. the entire body of the packet is secured

    5. security associations are established only where identity is
       authenticated by a know certificate authority or other pre-shared
       key

    6. both on-path and off-path third-party spoofing attacks   must be
       defeated

==> these should be numbered from 1 to 3, as you're referring to (1) and (2)
in the text below...

    [2]   Baker, F. and P. Savola, "Ingress Filtering for Multihomed
          Networks," RFC 2827 / BCP 84, March 2004.

    [12]  Ferguson, P. and D. Senie, Network Ingress Ingress Filt
          Defeating Denial of Service Attacks which employ IP Add
          Spoofing," RFC 2267 / BCP 38, May 2000.

==> BCP 84 is RFC 3704 while BCP 38 is 2827; earlier version of BCP 38 was
2267.

    [38]  Touch, J., "ANONsec: Anonymous Security to Defend Again
          Spoofing Attacks," draft-touch-anonsec-00 (work in prog
          May 2004.

    [5]   Better Than Nothing Security [BTNS] BOF, IETF-61, Wash. DC.,
          http://www.ietf.org/ietf/04nov/btns.txt

==> these (and the text where they're referred to) have since been somewhat
obsoleted.  Maybe it would be sufficient to refer to the latest BTNS WG
docs and/or the BTNS charter?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm