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

[Jari Arkko <[e-mail]>]

I have reviewed this draft. It is a very well written document and I 
have sent it forward to an IETF last call. I did have a few issues, 
however, and I would like to ask the authors to take a look during the 
last call and issue a new revision if they think it is appropriate:

> This both that the information be useable (logging), and that the
> information be accurate, i.e. that no other machine could have been
> using that address.
>   

There is something odd in this sentence.

> Furthermore, BCP 38 <http://tools.ietf.org/html/bcp38> only implies source address
> verification at the Internet Layer, and is most often implemented on
> IP subnetwork address boundaries. 

maybe "... solely at the Internet layer ...."

> For example, Internet
>    devices can confirm that:
>
>    o  The IP source address is appropriate for the lower layer address
>       (they both identify the same system)
>
>    o  The IP source address is appropriate for the device at the layer 2
>       switch port (the address was assigned to a, and perhaps the,
>       system that uses that port)
>   
> For example, a device that has
>    an authoritative table between Link Layer and IP addresses on a link
>    can discard any datagrams in which the IP address is not associated
>    with the Link Layer address in the datagram.  

I think it is important to already here acknowledge the fact that the 
mappings are not as straightforward as one might think. For instance, 
you could make this change:

s/The IP source address is appropriate for the lower layer address (they 
both identify the same system). Naturally, reliance on such a check 
requires the ability track what
the correct address mappings are, including hosts with multiple 
addresses and other complications."

> However, two primary areas exist that
>    can complicate such techniques.  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 via a single physical port.  Furthermore, if one
>    or more dynamic address allocation mechanisms such as DHCP are
>    employed, then some mechanism must exist to associate those IP layer
>    addresses with the appropriate Link layer ports, as addresses are
>    allocated or reclaimed.
>   

I would think that the third area is movements between ports (e.g., due 
to a wireless host moving from one AP to another)

> 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 think you could make an even stronger statement here. "If one has a 
switched network of hosts, but tries to only provide address enforcement 
on the routers on the network, ..."

> The most obvious example of devices that are problematic when
> attempting to implement port-MAC-IP bindings is that of routers.
> Routers not only originate packets themselves and often have multiple
> interfaces, but also forward packets from other network segments.  As
> a result, it's difficult for port-MAC-IP binding rules to be
> established a priori, because it's likely that many addresses and IP
> subnets should be associated with the port-MAC in question.
>   

You might want to note that there are exceptional cases, such as prefix 
delegation where this knowledge is available.

> may forward traffic from an array of address
addresses

> 5.2.6. Mobile IP
>
>
>    Mobile IP hosts in both IPv4 and IPv6 are proper members

I would generalize this to 5.2.6 Mobile hosts, keep the original text, 
but add at the front some discussion of hosts that move around. This too 
is an important case.

Jari