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

[Jari Arkko <[e-mail]>]

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