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

From: Jari Arkko <[email-masked]>
Date: Wed, 04 May 2011 11:13:15 +0200

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

---

From: Joel Halpern <[email-masked]>
Date: Thu, 5 May 2011 11:22:05 -0400

Almost all of these suggests (elided) look helpful and actionable.  I will do as you suggest.
However, I am not sure what to actually do with the last one.
Yours,
Joel

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Wednesday, May 04, 2011 5:13 AM
To: SAVI Mailing List; [email-masked]
Subject: AD review of draft-ietf-savi-threat-scope

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 06 May 2011 11:28:29 +0200

How about this:

5.2.6. Mobile Hosts

Hosts may move around from switch port to another, either due to being 
physically moved into a different port, or due to roaming to a wireless 
access point that is attached to a different switch port. These 
movements cause an address to suddenly appear at a different part of the 
topology, or even appear to move back and forth between different 
points. SAVI solutions should be able to deal with such movements.

Mobile IP hosts in both IPv4 and IPv6 are proper members ... (text 
continues as it was) ...

Jari

---

From: Joel Halpern <[email-masked]>
Date: Fri, 6 May 2011 11:35:33 -0400

Works for me.
Thanks,
Joel 

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Friday, May 06, 2011 5:28 AM
To: Joel Halpern
Cc: SAVI Mailing List
Subject: Re: AD review of draft-ietf-savi-threat-scope

How about this:

5.2.6. Mobile Hosts

Hosts may move around from switch port to another, either due to being physically moved into a different port, or due to roaming to a wireless access point that is attached to a different switch port. These movements cause an address to suddenly appear at a different part of the topology, or even appear to move back and forth between different points. SAVI solutions should be able to deal with such movements.

Mobile IP hosts in both IPv4 and IPv6 are proper members ... (text continues as it was) ...

Jari