[savi] AD review of draft-ietf-savi-framework

[Jari Arkko <[e-mail]>]

I have reviewed this draft.

I think it is in relatively OK shape, though I had a number of issues. 
Please see below.

I'm expecting a new version, and then I can start the IETF last call for 
this document.

> Finer-grained IP
> source address validation would be helpful to enable IP-source-
> address-based authentication, authorization, and host localization,
> as well as to efficiently identify misbehaving hosts.  

I would cut down this list a little bit. Source-address based 
authentication may not be recommended practice to begin with. Just say:

   Finer-grained IP
   source address validation would ensure that source address
   information is accurate, reduce the ability to launch
   denial-of-service attacks, and help with localizing hosts
   and identify misbehaving hosts.



> This model allows a SAVI instance to be located anywhere on the link
> to which the hosts attach, hence enabling different locations for a
> SAVI instance.

The term "SAVI instance" sounds a bit odd. Perhaps you could say "... 
allows SAVI functionality (a SAVI instance) to be located ...."

> To make SAVI of better applicability, to handle the scenarios in
> which hosts are not directly attached is of value.
>    SAVI instance is attached by a legacy switch which is attached by
>    hosts.

The language could be improved here.

> However, to take such scenario into consideration requires
> support in the bind-and-identify model.
> o  A legacy switch to which hosts are attaching uses two trunked
>    ports to connect to SAVI switch.
>
> o  STP runs among switches, and a link failure happens.
>
> Both scenarios require more specified design to build correct
> binding.  Thus, for each SAVI solution, the applicability must be
> specified explicitly.
>   

I'm not sure what this means. Please rewrite in clearer language. In 
particular, I had the following questions:

- What specific new support is needed in the bind-and-identify model?

- Is the bind-and-identify model the one that you introduced earlier? 
You're calling it with a different name ... based on the beginning of 
the Section, it should perhaps be called Identify-Bind-Enforce model.

- Link failures make for complex effects to SAVI. Mere disconnection by 
itself is not a problem, packets just don't flow. Network partition and 
re-merge would cause some problems.

One possible rewrite:

Nevertheless, it is useful for SAVI mechanisms to be able to handle 
situations where hosts are not directly attached to the SAVI-capable 
device. For instance, deployments with both SAVI-capable and legacy 
switches could be supported. In general, a SAVI solution needs to 
specify how it deals with a number of deployment scenarios and 
exceptional situations, including interaction with legacy devices, hosts 
moving between wireless attachment points, network partitions, and so on.

> o  A legacy switch to which hosts are attaching uses two trunked
>    ports to connect to SAVI switch.
>   
to a SAVI capable switch

> The SAVI method hence comes in multiple variants:
> for links with Stateless Address Autoconfiguration [rfc4862 <http://tools.ietf.org/html/rfc4862>], for
> links with DHCP [rfc2131 <http://tools.ietf.org/html/rfc2131>][rfc3315], for links with Secure Neighbor
> Discovery [rfc3971 <http://tools.ietf.org/html/rfc3971>], for links with IKEv2 [rfc5996 <http://tools.ietf.org/html/rfc5996>] [rfc5739 <http://tools.ietf.org/html/rfc5739>]
> [rfc5026 <http://tools.ietf.org/html/rfc5026>] and for links that use any combination of IP address
> assignment methods.
>   
SEND is perhaps more of a variation ofg SLAAC than its own free-standing 
address allocation method.

> The reason to develop SAVI method variants for each single IP address
> configuration method, in addition to the variant that handles all IP
> address assignment methods, is to minimize the complexity of the
> common case:  many link deployments today either are constrained to a
> single IP address assignment methods or, equivalently from the
> perspective of the SAVI method, separate IP address assignment
> methods into different IP address prefixes.  The SAVI method for such
> links can be simpler than the SAVI method for links with multiple IP
> address assignment methods per IP address prefix.
>   

Hmm. I'm not sure I buy this. First of all, I would claim that many 
links support multiple address assignment methods. For instance, dual 
stack links typically today support SLAAC for IPv6 and DHCP for IPv4. 
And its obvious that to fly in the IETF, the SAVI solution needs to 
support multiple methods. I would just replace the above text with:

To provide a complete solution, SAVI methods need to support a variety 
of address configuration mechanisms. Of course there may be different 
SAVI specifications that specify, for instance SAVI functionality for 
IPv4 and IPv6 address configuration. It is expected that SAVI methods 
can collectively support DHCP [rfc2131,rfc3315], Stateless Address 
Autoconfiguration [rfc4862 <http://tools.ietf.org/html/rfc4862>] with or 
without Secure Neighbor Discovery [rfc3971], IKEv2 
[rfc5996,rfc5739,rfc5026] and combinations thereof.

>
>     6. Mix Scenario
>

Mixed Scenario?

> o  Manually Prefix Configuration:  The allowed prefix scope of IPv4
>    Addresses, IPv6 static addresses, IPv6 addresses assigned by
>    SLAAC, and IPv6 addresses assigned by DHCPv6 can be set manually
>    at SAVI device. FE80::/64 is always a feasible prefix in IPv6.
>   

I think you want:

o   Manual Prefix Configuration: ...

> o  Prefix Configuration by RA Snooping:  The allowed prefix scope of
>    IPv6 static addresses and IPv6 addresses assigned by SLAAC can be
>    set at SAVI device through snooping RA message at SAVI device.
>    FE80::/64 is always a feasible prefix in IPv6.
>
> o  Prefix Configuration by DHCP-PD Snooping:  The allowed prefix
>    scope of IPv6 static addresses, IPv6 addresses assigned by SLAAC,
>    and IPv6 addresses assigned by DHCPv6 can be set through snooping
>    DHCP-PD message at SAVI device. FE80::/64 is always a feasible
>    prefix in IPv6.
>
>   
I don't think the FE80::/64 statement is needed on these two bullets 
(RAs and DHCP-PD do not use FE80 AFAIK.)

> If some of the prefix scopes is set to have non prefix, it implies
> corresponding address assignment method is not allowed in the
> network.
>   
... no prefix, it implies ...

>    The author would like to thank the SAVI working group for a thorough

The authors...

> This document only discusses the possible methods to mitigrate the
> usage of forged IP address, but doesn't propose a mechanism that
> provides strong security for IP address.
I'd say:

   This document only discusses the possible methods to mitigate the
   usage of forged IP addresses. Some such methods may rely on
   cryptographic methods, but not all do. As a result, it is generally
   not possible to prove address ownership in any strong sense.

Jari