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

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Dec 2010 19:30:09 +0200

I reviewed this draft. A few comments below. I also glanced at the 
reviews from Pekka, Marcelo, and Eric, and mostly agree with their 
comments as well. In particular I agree with Pekka that this document 
would benefit from being scoped more tightly and that it would be an 
improvement to remove extra parts of the document.

In general, this document is on the right track, but does need some 
work. The main issue seems to be more in the area of the document saying 
too much than having missing information.

> One of the difficulties in
> encouraging the deployment of BCP 38 is that there is relatively
> little benefit until it is very widely deployed, which is not yet the
> case.  The local application of the principle of BCP 38 fortunately
> has local benefit, even before BCP 38 is fully deployed.  It also
> helps get the Internet towards a state where BCP 38 is more widely
> followed.

I'm not sure I follow the logic here.  The main problem with BCP 38 is 
that you are primarily protecting others when you deploy it in your 
network. Are you saying something subtle about the difference between 
"principle of BCP 38" and "BCP 38" itself? Why is the first sentence in 
apparent contradiction with the second one?

>    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.
>
Please be more specific about what this attack is. This description is 
insufficient.

>    It should be noted that while BCP 38 directs providers to provide
>    protection from spoofed prefixes, it is clearly desirable for
>    enterprise operators to provide that protection more locally, and
>    with better traceability.

I.e., higher granularity would be useful.

> 3.1.5. Reflective Attacks
>
>
>    DNS reflective amplification attacks are a particularly potent DoS
>    attack vector on the Internet today. 

I would use DNS as an example, but reflection attacks are more general. 
I'm not sure there is any need to limit yourself to just DNS based 
reflection attacks.

Missing blind attacks: I though there was a TCP RST attack which would 
enable you to shut down BGP sessions, given enough packets to play with. 
Not sure if this is covered anywhere yet.

> If the port to which the
>    attacker is connected were to implement policy that binds a single
>    Link Layer and IP address tuple to that port upon initial
>    provisioning, spoofed packets, at the Link Layer and/or Network
>    Layer, would be discarded on ingress.

I would keep solutions out of Section 3.

> 4.1. Host to link layer neighbor via switch
>
>
>    The first point at which a datagram with a spoofed address can be
>    detected is on the link to which the source of the datagram is
>    connected.  At this point in the network, the source Link Layer and
>    IP addresses are both available, and can be verified against each
>    other.  A datagram in which the IP source address does not match the
>    corresponding Link Layer address can be discarded.  Of course, the
>    trust in the filtering depends on the trust in the method through
>    which the mappings are developed.  This mechanism can be applied by a
>    first hop router, or switch on the link.  The first hop switch has
>    the most precise information for this.
>
>    On a truly shared medium link, such as classic Ethernet, the best
>    that can be done is to verify the Link Layer and IP addresses against
>    the mappings.  When the link is not shared, such as when the hosts
>    are connected through a switch, the source host can be identified
>    precisely based on the port through which the datagram is received or
>    the MAC address if it is known to the switch.  Port identification
>    prevents transmission of malicious datagrams whose Link Layer and IP
>    addresses are both spoofed to mimic another host.
I have a feeling that this description is too simplistic, in the face of 
mobile hosts, wireless switches, multiple interface cards and the like. 
I'm not asking you to make the description more complete, but it may be 
worthwhile to see how much you really need to say here and whether you 
can point to some of the other documents in the WG for the details.

> 4.4. ISP NNI Router to ISP NNI Router
>
>
>    The considerations explicitly related to customer networks can also
>    be applied to neighboring ISPs.  An interconnection agreement might
>    be written between two companies requiring network ingress filtering
>    policy be implemented on all customers connections.  ISPs might, for
>    example, mark datagrams from neighboring ISPs that do not sign such a
>    contract or demonstrably do not behave in accordance with it as
>    'untrusted'.  Alternatively, the ISP might place untrusted prefixes
>    into a separate BGP community and use that to advertise the level of
>    trust to its BGP peers.

Its not clear why peering with another ISP would imply a different level 
of trust than any connection to the rest of the Internet. As we know, 
there are parts of the Internet that do not employ BCP 38, so it would 
seem that the rest of the Internet is in general "untrusted" in this 
sense. However, since it is necessary to communicate with the rest of 
the Internet its hard to see what the practical significance of this is, 
other than perhaps as a criteria for narrowing down the search when a 
problem occurs.

>
> In particular, these areas involve
>    topologies where more than a single IP layer address may be
>    associated with a MAC address on a given port, or where multiple
>    hosts are connected to a single IP port. 

What is an "IP port"?

> 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.
>
This does not seem to be related to the topic of the document too closely.

> 4.12. Residual Attacks
>
>
>    It should be understood that not all combinations of network, service
>    and enforcement choices will result in a protectable network.  For
>    example, if one uses conventional SLAAC, in a switched network, but
>    tries to only provide address enforcement on the routers on the
>    network, then the ability to provide protection is severely limited.

I'm not sure SLAAC is the issue here. If enforcement is on the routers, 
there's little to be done even with non-SLAAC address assignment mechanisms.

>    In a strictly static environment, configuration management for access
>    filters that map Link Layer and Network Layer addresses on a specific
>    switch port might be a viable option.  However, most networks,
>    certainly those that accommodate actual human users, are much more
>    dynamic in nature.  As such, mechanisms that provide port-MAC-IP
>    bindings need to accommodate dynamic address allocation schemes
>    enabled by protocols such as DHCP, DHCPv6 for address allocation, and
>    IPv6 Stateless Address Autoconfiguration.
>
>
I would add prefix delegation to this list.

> 5.3. IPv6 Considerations
>    ...
>
>    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.

Lets be specific here. Switches do not need to store IP address 
information, they work on L2 addresses. So only switches that attempt to 
do some form of SAVI functionality would need more memory.

Jari

---

From: Fred Baker <[email-masked]>
Date: Mon, 6 Dec 2010 11:31:15 -0800

On Dec 6, 2010, at 9:30 AM, Jari Arkko wrote:

> I reviewed this draft. A few comments below. I also glanced at the reviews from Pekka, Marcelo, and Eric, and mostly agree with their comments as well. In particular I agree with Pekka that this document would benefit from being scoped more tightly and that it would be an improvement to remove extra parts of the document.
> 
> In general, this document is on the right track, but does need some work. The main issue seems to be more in the area of the document saying too much than having missing information.
> 
> I'm not sure I follow the logic here.  The main problem with BCP 38 is that you are primarily protecting others when you deploy it in your network. Are you saying something subtle about the difference between "principle of BCP 38" and "BCP 38" itself? Why is the first sentence in apparent contradiction with the second one?

BCP 38 is generally implemented using uRPF or filters on the upstream's link; the upstream will accept traffic from its customer if and only if the source address is appropriate to the customer. We think of this as "remote" - the customer is "somewhere else". It also has a weakness; while it protects the upstream and other networks beyond it from attacks from the network of interest, it doesn't protect that network in any sense.

Cisco's IPv4 Source Guard (and I presume others like it from other vendors) was developed in response to requirements from our customers that wanted a feature that protected themselves from themselves, and prevented attacks within the local area network. To my understanding, Tsinghua, which has been active in this discussion, has a similar concern. For what it's worth, the week following the IETF I was in Singapore and got customer feedback about a data center switch from a customer there; this particular switch is L2-only, and the customer specifically wanted SAVI-style protection within his local area network. 

The "apparent contradiction" you see between the first and second sentences revolves around the distinction between BCP 38, which is an ISP function applied to customers and therefore remote vs use in a local area network. That's why the sentence opens with "The local application of the principle". BTW, Cable Modem and DSL networks are quite often local area networks in the sense of the kind of equipment they use; some of our largest users of IPv4 Source Guard are residential access networks. 

> Please be more specific about what this attack is. This description is insufficient.

This is an attack that Arbor observed somewhere along the way, a variation on a SYN attack. Danny would have to go further into what he saw, but from the description it should be straightforward to recreate (for some given address X, send a TCP SYN packet from X to X).

> I would use DNS as an example, but reflection attacks are more general. I'm not sure there is any need to limit yourself to just DNS based reflection attacks.
> 
> Missing blind attacks: I though there was a TCP RST attack which would enable you to shut down BGP sessions, given enough packets to play with. Not sure if this is covered anywhere yet.

Well, yes. If I have reason to believe that {address X port X'} has a TCP connection with {address Y port Y'}, and I can bombard one of them with RSTs using random TCP sequence numbers, there is some chance that one will land within the current TCP window and shut down the session. That is, as you say, most fruitful with long-running TCP sessions such as BGP uses, which in turn have other effects such as on routing. It also applies to NFS/TCP and to other uses of long-lived TCP sessions.

The BGP attack could be discussed specifically. Are you saying you would like us to? While I agree that SAVI would help mitigate such attacks, the usual mitigation is to protect the TCP session at its endpoints, using TCP-MD5 or IPsec.

> I have a feeling that this description is too simplistic, in the face of mobile hosts, wireless switches, multiple interface cards and the like. I'm not asking you to make the description more complete, but it may be worthwhile to see how much you really need to say here and whether you can point to some of the other documents in the WG for the details.
> 
> Its not clear why peering with another ISP would imply a different level of trust than any connection to the rest of the Internet. As we know, there are parts of the Internet that do not employ BCP 38, so it would seem that the rest of the Internet is in general "untrusted" in this sense. However, since it is necessary to communicate with the rest of the Internet its hard to see what the practical significance of this is, other than perhaps as a criteria for narrowing down the search when a problem occurs.
> 
>> 
> I'm not sure SLAAC is the issue here. If enforcement is on the routers, there's little to be done even with non-SLAAC address assignment mechanisms.
> 
> Lets be specific here. Switches do not need to store IP address information, they work on L2 addresses. So only switches that attempt to do some form of SAVI functionality would need more memory.

Thanks

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Dec 2010 22:28:37 +0200

Fred,

> The "apparent contradiction" you see between the first and second sentences revolves around the distinction between BCP 38, which is an ISP function applied to customers and therefore remote vs use…

Ok. Its clearer now. But I still did not get it without your 
explanation. Maybe there's room for improving the text.

> The BGP attack could be discussed specifically. Are you saying you would like us to? While I agree that SAVI would help mitigate such attacks, the usual mitigation is to protect the TCP session at…

I think it would be useful to mention (but not go into depth or discuss 
solutions).

Jari