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

From: Joe Touch <[email-masked]>
Date: Sat, 18 Feb 2006 13:44:31 -0800

Hi, all,

Sorry for the long delay; I had been incorporating Ted's extensive
comments, and had not noted how these were handled yet. An update (03)
has been submitted with those and the following mods addressed as noted
below:

Pekka Savola wrote:
> 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.
...
> 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.
> 
> ....  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.

Done.

> (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.

Updated.

>  b) TTL checking problem with tunnels is still inaccurate. 

Updated.

>  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.

The text has been updated to clarify its original intent. I disagree
that "you can _yourself_ do the filting, without relying on anyone
else", except in trivial multiconnected stub network cases.

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

The section where this is mentioned talks about the processing
comparison of network and transport authentication; both are forms of
authentication with similar computational complexity. That's why this
section focuses on the other issues, such as demultiplexing and storage.

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

Section 4 was updated to clarify this point.

> 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.

The text above says "without knowing who the client is". It isn't
meaningful to talk about MITM in those cases - the MITM is the client at
that point. IMO, the text already has the sufficient caveat, and
sufficiently explains the protection provided.

> 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.

Updated earlier in sec 5.2 as to computational complexity.

>    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.

This paragraph is talking about key distribution; it is the earlier one
that talks about computation.

> 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.)

Dedicated IPsec hardware is very cheap (e.g., for 100Mbps streams), and
IMO should be added to routers to protect their management CPUs from
computational overload. We have another draft in progress to talk about
reducing the CPU overload of IPsec, esp. for DOS attacks, but that was
already deemed out of scope for BTNS. I.e., computational effort was
taken off the table there during the BOF stages (despite my efforts to
the contrary ;-)

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

The document makes comparisons and recommendations in those contexts
throughout; I don't know if it's feasible to summarize them in a single
paragraph at the end.

...
> ==> 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.

The recommendations have been there in several revisions with WG
opportunity to comment, and have been revised accordingly several times
already.

> 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.

Done.

>    [...] 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 ?

Typo. Fixed as "approximately 65,000", which is sufficient for this doc.
I didn't want to get deep into which numbers cannot be used as source
ports (it seemed like unassigned ones shouldn't, but I couldn't verify
that).

>    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.

Fixed.

>   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).

Fixed.

>    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.

Fixed.

>    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...

fixed.

>    [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.

Fixed (thanks for the catch).

>    [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?

Fixed.

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