Subject: [savi] draft-ietf-savi-threat-scope review

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 06 Oct 2010 15:00:25 +0200

Hi,

Find my comments about this document below.

General comment about the scope of section 3. I understand that the focus
of the section  should focus on the particular case that is relevant to 
SAVI,
namely that we assume that ingress filtering is deployed, then what are the
residual threats that remain and that SAVI can help to deal with.
I don't see that being exactly the focus of the document, so maybe i am 
wrong.
In any case, i include several comments below trying to focus the 
document more
on this.

In the terminology, i would suggest removing some very obvious terms,
such as IP address, TCP, MAC address. I find hard to imagine anybody
that doesn't understnad these terms that will be able to read the document.

In section

3.1.1.  Single Packet Attacks

    An example of an attack that can cause a receiving system to crash is
    a LAND attack.  A LAND attack packet would consist of an attacking
    system forwarding a packet (e.g., TCP SYN) to a target system that
    contains both a source and destination address of that target system.
    The target system would "lock up" when creating connection state
    associated with the packet, or would get stuck in a state where it
    continuously replies to itself.

I fail to understand why the system will continuously replies to itself.
I mean assuming that it actually accepts the SYN packet, it would reply
with a SYN+ACK and then with an ACK and establish the connection. Since
there is no data, this would simply result in a TCP block that is unused,
very similar to a half-open connection. So, the only impact would be
some state in the host, which if happens a lot could result in a DoS
attack, but this wouldn't be a single packet attack.
Similarly, i fail to understand why would a system "lock up" in this
situation unless it has a bug.
So, i wonder if these single packets attacks don't actually rely on
exploiting bugs in poorly coded stacks (which may be frequent), like
the case of sending overlapping fragments and the like.
If that is the case, i would suggest to state that explicitly i.e.
that the attack rely on exploiting a code bug rather than a protocol
vulnerability.

Later  on, in the same section it reads:

    Another class of a single packet attacks involves an attacker
    poisoning network or DNS cache information, perhaps to simply break a
    given host's connection, enable MITM or other attacks.  Network level
    attacks that could involve single packet DoS include ARP cache
    poisoning and ICMP redirects.  The most obvious example which depends
    upon falsifying an IP source address is an on-link attacker poisoning
    a router's ARP or ND cache.

How is this a blind attack? I mean, afaiu, a blind attack is one where the
attacker is off-path, in this case, if i understand it properly, the
attacker is on path, right?
Maybe the ARP/ND poisoning should move to the non blind attacks? Maybe the
DNS cache posoning would a better example for the blind attack? But in this
case, i think it would be important to highlight why it is useful to spoof
the source address of the packet.

Later on in section

3.1.2.  Flood-Based DoS  it reads:

    Because these attacks require no reply from the target system and
    require no legitimate transaction state, attackers often attempt to
    obfuscate the identity of the systems that are generating the attack
    traffic by spoofing the source IP address of the attacking traffic
    flows.  Because ingress filtering isn't applied ubiquitously on the
    Internet today, spoof-based flooding attack vectors are typically
    very difficult to traceback.  In particular, there may be one or more
    attacking sources beyond your network border, and the attacking
    sources may or may not be legitimate sources, it's difficult to
    discriminate if the sources are not directly connected to the local
    routing system.

This seems to motivate the deployment of ingress filtering, but this is
not exactly the point here right?
I mean, imho, the document would also need to state why even if ingress
filtering is deployed, why you would also need something like SAVI.
IMHO, this is the case and this is basically because suppose you have
deployed ingress filtering and you know that the DoS traffic comes from
a given subnet, what do you then? Do you shut down all the hosts in the
subnet? Having something like SAVI gives you a higher granularity and it
would in some deployment modes allow to identify the hosts that are
generating the DoS traffic and shut them down individually.

Later on section

3.1.3.  Poisoning Attacks

    While poison attacks can often be done with single packets, it is
    also true that a stream of packets can be used to find a window where
    the target will accept the incorrect information.  In general, this
    can be used to perform broadly the same kinds of poinsonings as
    above, with more versatility.

I understand this refers to the single packet attack section. Since this
section basically says that attacks can be done with one or more packets
i would suggest to integrate this section with the single packet section
name the section poisoning attacks, state that they can be performed with
one or several packets and that they can either exploit a bug to crash
down a system or can install false state that would disrupt the
communications.

Later on, in section  3.1.4.  Spoof-based Worm/Malware Propagation

think this is one of the critical application of SAVI. You want to be
able to identify the infected machines to clean them up. By spoofing the
source address, the worm makes the local admin job harder and this is
where SAVI can help. I would mention that explicitly.

In sections3.1.5.  Reflective Attacks and3.1.6.  Accounting Subversion

I think it would be relevant to discuss the differences in the threats
of SAVI versus ingress filtering in these cases.

In section3.1.7.  Other Blind Spoofing Attacks

    Other Blind spoofing attacks might include spoofing in order to
    exploit source routing or other policy based routing implemented in a
    network.  It may also be possible in some environments to use
    spoofing techniques to perform blind or non-blind attacks on the
    routers in a site or in the Internet.

If the attack is non blind, it doesn't belong to this section.
Maybe you should move the whole section to a section 3.3 and call
it Other attacks?

In section

3.2.1.  Man in the Middle (MITM)

    For example, an attacker with access to a host on LAN segment may
    wish to redirect all the traffic on the local segment destined for a
    default gateway address (or all addresses) to itself in order to
    perform man-in-the-middle attacks.  In order to accomplish this the
    attacker might transmit gratuitous ARP [RFC0826] messages or ARP
    replies to the Ethernet broadcast address ff:ff:ff:ff:ff:ff,
    notifying all the hosts on the segment that the IP address(es) of the
    target(s) now map to it's own MAC address.

Now, this is actually a ARP cache poisoning attack, correct? I agree this is
a non blind attack and should be removed from section 3.1.1 above. I would
also highlight that this particular attack is not prevented by ingress filtering

General comment on section 4:
It seems to me that sections 4.1 through 4.7 are about the different parts of the
topology where enforcement can be placed, while sections 4.8 through 4.11 are
about actual techniques. Maybe it would be clearer to explicilty separate these two,
maybe in different sections or at least in different subsection in section 4.

Later on, in section

4.3.  ISP Edge PE Router

    An obvious special case of the discussion is with an ISP PE router,
    where it provides its customer with access.  BCP 38 specifically
    encourages ISPs to use ingress filtering to limit the incidence of
    spoofed addresses in the network.

    The question that the ISP must answer for itself is the degree to
    which it trusts its downstream network.  A contract might be written
    between an ISP and its customer requiring that the customer apply the
    procedures of network ingress filtering to the customer's own
    network, although there's no way upstream networks would be able to
    verify this.

I think an important case that may be good to discuss here is the case where
the CPE is a NAT and it has a single address assigned. In this case,
the PE router can actually enforce the usage of the right address.

Later on section

4.5.  Spoofing In Local Area Network Segments

    On Link Layer segments where multiple hosts reside, or a single MAC
    address can be associated with a port or interface, if a binding
    between a hardware address (e.g., MAC address) and corresponding IP
    address(es) are not provisioned via some means (either manual or
    dynamic mechanisms), then an attacker may exploit attack vectors that
    enable MITM or other spoof-based attacks.

I don't understand the point of this section. It seems redundant with
section 4.1 which already states that in shared medium, you need to bind
the source address with some L2 information and if not spoofing can
happen. I would suggest removing this section completely.

Later in section:

4.6.  Cable Modem Subscriber Access

    Cable Modem Termination Systems (CMTS) employ DOCSIS Media Access
    Control (MAC) domains, which are similar to Ethernet LAN
    environments.

Again, the comments made in section 4.1 apply to any shared medium.
As this section doesn't provide any information other that cable is
a shared medium, i would suggest removing it as well.
The other option, maybe it would be goo to integrate this section
about cable and the next section about DSL into section 4.3 and disucss
the different things that the PE router can enforce depending on the
technology used for access? (maybe you need to remane the section, since
it may not be exactly the PE who will enforce, but basically the enforcement
would happen in the ISP infrastrcutre facing the clients)

Later on in section

4.10.  Port-based Address Binding

    Much of the work SAVI appears to be initially targeting is aimed at
    minimizing source address spoofing in the LAN.  In particular, if
    mechanisms can be defined to accommodate configuration of port
    binding information for IP and MAC layer addresses in LAN
    environments, a large portion of the spoofing threat space in the LAN
    can be marginalized.

I think you should clarify whether you are talking about binding the
IP address to a MAC address or to a port. I mean, if you bind the IP address
to a port, you don't need to bind it to the MAC address, i guess.
OTOH, you can bind it to the MAC address and not to the port or you can
bind it to both.

Later in section

4.10.2.  Automated Binding

    For IPv4 the primary and very widely used automated binding technique
    is DHCP based address assignment.  Controlling where authoritative
    information can be sourced, coupled with sniffing and enforcing the
    assignments is an effective technique.

    For IPv6, there are two common automated address binding techniques.
    While there are many variations and details, for purposes of
    understanding the threats and basic responses, these are Stateless
    Address AutoConfiguration (SLAAC) and DHCPv6 based address
    assignment.  In both cases, binding establishment needs to be tied to
    the state machines for these protocols, and appropriate message
    sniffing and enforcement.  For DHCPv6 based techniques, it is also
    necessary to use classification techniques to ensure that responses
    come from authoritative sources.

So, i think the terminology could be improved here. It seems to me that
you are using binding to mean two different things: the assignment of
an IP address to an interface and the SAVI binding.
I think it would be useful to use different terms and explain how
these two relate

Later on it reads:

4.10.3.  IEEE 802.1X

    IEEE 802.1x is an authentication protocol that permits a network to
    determine the identity of a system seeking to join it and apply
    authorization rules to permit or deny the action.

Right, and....?
I guess some text is missing here to explain how this relates to SAVI?

Later on it reads:

4.11.  Cryptographic Techniques

    Needless to say, MITM and replay attacks can typically be mitigated
    with cryptographic techniques.  However, many of the applications
    today either don't or can't employ cryptographic authentication and
    protection mechanisms.  ARP for IPv4 does not use such protection.
    While SEND provides such protection for IPv6 ND, SEND is not widely
    used to date.

Well,, we are defining SAVI for SEND, so i think it would make sense to
make a more positive comment about this. OTOH, i think it is worth
noting that SEND only provides crypto material for signalling packets
and not for data packets, which we actually care the most.

Later on it reads:

5.3.  IPv6 Considerations

    IPv6 introduces additional capabilities which indirectly complicate
    the spoofing analysis.  IPv6 introduces and recommends the use of
    stateless address autoconfiguration (often referred to as SLAAC).
    This allows hosts to determine their IP prefix, select an ID, and
    then start communicating.  While there are many advantages to this,
    the absence of control interactions complicates the process of
    behavioral enforcement.

    An additional complication is the very large ID space.  Again, this
    64 bit ID space provided by IPv6 has many advantages.  It provides
    the opportunity for many useful behaviors.  However, it also means
    that in the absence of controls, hosts can mint anonymous addresses
    as often as they like, modulo the idiosyncrasies of the duplicate
    address procedure.  Like many behaviors, this is a feature for some
    purposes, and a problem for others.  But it does have implications
    for switch cost; the switch needs to store more addresses and so
    needs more memory.

Right, while this is true, it is also the case that as the v6 addresses
assigned to a link is huge, it is not possible for the attacker to use
SAVI as a DoS tool, by aqcuiring all the available addresses, which is
a real problem in v4. It may be worht noting that as well.

Later on it reads:

8.  Deployment Considerations

     From a global Internet perspective, deployment of anti- spoofing
    techniques tends to suffer from a "tragedy of the commons" situation.

I fail to see why this is a tragedy of the commons, since the tragedy of
the commons relates to overuse of a common resource, rather than inaction.
I think deployment of ingress filtering has an incentive problem instead.

later on it reads:

  A similar situation occurs with de-
    aggregation of Internet routing information for multi-homing and
    traffic engineering purposes, as well as the lack of explicit inter-
    domain routing prefix filters on the Internet.

this _may_ be consdiered as a tragedy of the commons, since there is
an abusive usage of a resource i.e. the global routing table.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 6 Oct 2010 16:50:40 -0400

Hi Marcelo,
   Just one response inline.

> situation unless it has a bug.

I think that the text in the draft is not complete. This is what is 
causing the confusion. Let me try to explain the LAND attack as best as 
I remember (It was a loooong time ago). The important point that the 
text does not state is: not only do the source and destination address 
need to match, the source and destination port need to match as well for 
this attack to work. And yes, it worked only on certain stacks. I 
remember some of the Cisco boxes were affected, along with FreeBSD, Win 
95 and NT. I cannot believe any modern system still has this vulnerability.

Thanks
Suresh

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Oct 2010 13:55:52 -0400

I can readily agree that the text is incomplete.  I would appreciate 
assistance if anyone else can add to Suresh' description.  Given a 
complete set of pieces, I can synthesize additional text for the document.

Thank you,
Joel

On 10/6/2010 4:50 PM, Suresh Krishnan wrote:
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 12 Oct 2010 20:07:33 +0200

i personally would be perfectly fine to simply state that using 
packets with spoofed source address for example with the source and 
destination address being equal to the one of the target host can result 
in attacks that exploit bugs in the target host stack and resulting in 
malfunction and/or crash.

I mean, i would be fine wihtout an exact description of that particular 
attack, but i was missing the point that this exploits bugs in 
implementations

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 18 Oct 2010 17:56:15 -0400

Hi Joel/Marcelo,
   I am fine either way. Marcelo's idea of a generic description sounds 
fine to me, and I am willing to craft more specific text if needed.

Thanks
Suresh