Source Address Validation Improvement (SAVI) Framework
draft-ietf-savi-framework-06

[Ballot comment]
Thanks for adding the RFC editor note to handle my discuss
point.

--- original comments below, not sure if those are taken into
account or not

- general: The term "legitimate IP address" is used a good few
times, and is sort-of defined in the 1st bullet of section 3,
but a clearer definition would be good - I think you mean that
"legitimate" == "not considered a spoofed source by SAVI" and no
more, (which is fine), but it could be read to mean "authorised
by the authorities" which would give the wrong impression (I
hope:-). You might even consider inventing your own term for
this, e.g. "SAVI-legitimate" or whatever (but I'm only weakly
suggesting that, I can understand that inventing such a term
might just cause more confusion now).

- p4, maybe s/network operators/network administrators/? The
term "operator" tends to be taken to mean a specific type
of admin.

- p4, Is "on the path" right really? SAVI devices need to
be close to the host as is correctly stated elsewhere.

- p5, Is "must be verifiable" correct in point#2? I think it
would be better to say "needs to be verifiable....if SAVI is to
work"

- p6, What foes "full protection for the hosts" mean? SAVI is
not protecting the host with the source address, but rather
the network or the receiving hosts and doesn't provide "full"
protection in any sense I can understand? Maybe just end
that sentence at "lower" is the easiest change.

- p6, Is it correct to say that it is through "assignment"
that a host becomes the "legitimate" user of a source
address for all cases? (Just checking.)

- p7, Are all of the examples of binding anchors listed in
3.2 in scope of the SAVI WG? I think it'd be good to say
which are or are not, if not all are or maybe to only list
those that are in scope.

- p11, What is a "premier check"?

- The secdir review also suggests a number of minor
changes.

    http://www.ietf.org/mail-archive/web/secdir/current/msg02960.html

[Ballot comment]
The Gen-ART Review by Peter McCann on 2-Nov-2011 suggests many
  editorial improvements.  Please consider them.  The review can be
  found here:

    http://www.ietf.org/mail-archive/web/gen-art/current/msg06889.html

[Ballot discuss]
The Gen-ART Review by Peter McCann on 2-Nov-2011 raised a point that
  deserves a response:

  > The document presents the design of the SAVI model, and advocates
  > putting SAVI validators as close to the end host as possible,
  > forming a protection perimeter where there is some assurance that
  > source IP addresses are valid inside the perimeter.
  >
  > However, the document does not discuss the possibility that some
  > nodes inside the perimeter may be compromised or otherwise untrusted
  > (for example, in case there are multiple distinct administrative
  > domains connected in some topology).  This seems to be a case of
  > crusty on the outside, soft in the middle security.  Perhaps some
  > discussion of these issues is warranted.  For example, it might make
  > sense in some cases to deploy SAVI instances that do replicate state,
  > which is argued against in the draft on the basis of memory savings.

  Further, I agree with Stephen Farrel that a discussion of privacy
  implications is needed.  Please consider using the privacy terms in
  draft-iab-privacy-considerations-01.txt.

Russ, per discussion this year with Pete and with the current RFC Editor notes (see below), I think your discuss could be cleared.

Stephen, I've asked Joel for an update of the threat-scope draft to resolve your discuss here. (But. I'm trying to clear documents before I step down. Do you really think we need a discuss on this document, and not just on threat-scope? The issue is blocking two documents, but we will eventually solve it.)

> Yes, that would do.  I think being attached to a non-enforcing port is
> equivalent to being inside (outside?) the perimeter.
>
> -Pete
>
> 2012/1/16 Joel M. Halpern :
> Is what you wanbt a sentence that says:
> Note, if such configuration is used, care must be taken as any hosts on
> subnets attached to non-enforcing ports will be able to use spoofed
> source addresses?
>
> Yours,
> Joel
> RFC Editor Note
>
>  Please add this text to the end of the Security Considerations Section:
>
>  NEW:
>  Section 2 explained how the preferred location of SAVI instances is close to hosts. However,
>  in some cases this make the SAVI instances themselves vulnerable, and may defeat the purpose
>  of deploying a SAVI solution. For instance, deployments should not place SAVI functionality
>  in devices that are physically exposed. Even if the device correctly monitors the source address
>  usage of hosts, an attacker could replace the device with one that does not check, or hook up
>  to a trusted interface from the device to the rest of the network. Similarly, deployments where
>  SAVI instances are distributed across administrative boundaries are not recommended.
>  For instance, in most cases it would be undesirable to deploy a distributed SAVI solution
>  on both sides of a customer - provider interface, if the solution required trusting the correct
>  operation of the SAVI devices on the other side of the interface.
>
>  Please add this text to the end of Section 4:
>
>  NEW:
>  Note, if such configuration is used, care must be taken as any hosts on
>  subnets attached to non-enforcing ports will be able to use spoofed
>  source addresses?

[Ballot discuss]
No change in -06 to address this that I can see (note to self;-)

This makes no mention at all of privacy which I think needs to
be there somewhere. Given that Joel is planning to add text on
that to savi-threats I'd be fine if that is just referenced from
here, or even if that text is moved from savi-threats to this
document, and savi-threats could refer to it here. But the
privacy implications of SAVI do need to be covered here too.
(That assumes that Joel's text is as fine as I'm sure it
will turn out to be:-)

[Ballot comment]
- Ted Hardie also reviewed this from the privacy perspective
and had what I think is more or less the same concern as
in my discuss.

  http://www.ietf.org/mail-archive/web/privacydir/current/msg00059.html


- general: The term "legitimate IP address" is used a good few
times, and is sort-of defined in the 1st bullet of section 3,
but a clearer definition would be good - I think you mean that
"legitimate" == "not considered a spoofed source by SAVI" and no
more, (which is fine), but it could be read to mean "authorised
by the authorities" which would give the wrong impression (I
hope:-). You might even consider inventing your own term for
this, e.g. "SAVI-legitimate" or whatever (but I'm only weakly
suggesting that, I can understand that inventing such a term
might just cause more confusion now).

- p4, maybe s/network operators/network administrators/? The
term "operator" tends to be taken to mean a specific type
of admin.

- p4, Is "on the path" right really? SAVI devices need to
be close to the host as is correctly stated elsewhere.

- p5, Is "must be verifiable" correct in point#2? I think it
would be better to say "needs to be verifiable....if SAVI is to
work"

- p6, What foes "full protection for the hosts" mean? SAVI is
not protecting the host with the source address, but rather
the network or the receiving hosts and doesn't provide "full"
protection in any sense I can understand? Maybe just end
that sentence at "lower" is the easiest change.

- p6, Is it correct to say that it is through "assignment"
that a host becomes the "legitimate" user of a source
address for all cases? (Just checking.)

- p7, Are all of the examples of binding anchors listed in
3.2 in scope of the SAVI WG? I think it'd be good to say
which are or are not, if not all are or maybe to only list
those that are in scope.

- p11, What is a "premier check"?

- The secdir review also suggests a number of minor
changes.

    http://www.ietf.org/mail-archive/web/secdir/current/msg02960.html

[Ballot comment]
The Gen-ART Review by Peter McCann on 2-Nov-2011 suggests many
  editorial improvements.  Please consider them.  The review can be
  found here:

    http://www.ietf.org/mail-archive/web/gen-art/current/msg06889.html

[Ballot discuss]
The Gen-ART Review by Peter McCann on 2-Nov-2011 raised a point that
  deserves a response:

  > The document presents the design of the SAVI model, and advocates
  > putting SAVI validators as close to the end host as possible,
  > forming a protection perimeter where there is some assurance that
  > source IP addresses are valid inside the perimeter.
  >
  > However, the document does not discuss the possibility that some
  > nodes inside the perimeter may be compromised or otherwise untrusted
  > (for example, in case there are multiple distinct administrative
  > domains connected in some topology).  This seems to be a case of
  > crusty on the outside, soft in the middle security.  Perhaps some
  > discussion of these issues is warranted.  For example, it might make
  > sense in some cases to deploy SAVI instances that do replicate state,
  > which is argued against in the draft on the basis of memory savings.

  Further, I agree with Stephen Farrel that a discussion of privacy
  implications is needed.  Please consider using the privacy terms in
  draft-iab-privacy-considerations-01.txt.

[Ballot comment]
#1) s3.2 contains the following:

  The various binding anchors differ significantly in the security they
  provide.

The binding anchors in and of themselves provide no security.  I think maybe what you're trying to say is:

  The choice of a binding anchor influences the amount of security
  SAVI can provide.

And:

  IEEE extended unique identifiers, for example, fail to
  render a secure binding anchor ...

Maybe:

  IEEE extended unique identifiers, for example, fail to
  render a unique binding anchor ...

And then later:

  Given this diversity in the security provided,

with

  Given the diversity of binding anchors,

#2) s10: Contains:

  of forged IP addresses

shouldn't it be:

  of forged source IP addresses

#3) s10: Also contains:

  If
  binding anchor is not exclusive for each user, or is without strong
  security, addresses can still be forged.

Again, I'm not sure what it means for the binding anchor to have security.  The text in s3 talks about trying to make sure the address is unique for a give source.  I think you could delete the ", or ... ," part.

#4) s10: I'm having some trouble parsing this sentence:

  If there is
  requirement the usage of IP address must be of strong security, the
  only way is using cryptographic based authentication.

Could you just use the last sentence from the savi-threat-scope security considerations:

  The only technique to unquestionably verify source addresses of a
  received datagram are cryptographic authentication mechanisms such as
  IPsec.

[Ballot comment]
- Ted Hardie also reviewed this from the privacy perspective
and had what I think is more or less the same concern as
in my discuss.

  http://www.ietf.org/mail-archive/web/privacydir/current/msg00059.html


- general: The term "legitimate IP address" is used a good few
times, and is sort-of defined in the 1st bullet of section 3,
but a clearer definition would be good - I think you mean that
"legitimate" == "not considered a spoofed source by SAVI" and no
more, (which is fine), but it could be read to mean "authorised
by the authorities" which would give the wrong impression (I
hope:-). You might even consider inventing your own term for
this, e.g. "SAVI-legitimate" or whatever (but I'm only weakly
suggesting that, I can understand that inventing such a term
might just cause more confusion now).

- p4, maybe s/network operators/network administrators/? The
term "operator" tends to be taken to mean a specific type
of admin.

- p4, Is "on the path" right really? SAVI devices need to
be close to the host as is correctly stated elsewhere.

- p5, Is "must be verifiable" correct in point#2? I think it
would be better to say "needs to be verifiable....if SAVI is to
work"

- p6, What foes "full protection for the hosts" mean? SAVI is
not protecting the host with the source address, but rather
the network or the receiving hosts and doesn't provide "full"
protection in any sense I can understand? Maybe just end
that sentence at "lower" is the easiest change.

- p6, Is it correct to say that it is through "assignment"
that a host becomes the "legitimate" user of a source
address for all cases? (Just checking.)

- p7, Are all of the examples of binding anchors listed in
3.2 in scope of the SAVI WG? I think it'd be good to say
which are or are not, if not all are or maybe to only list
those that are in scope.

- p11, What is a "premier check"?

[Ballot discuss]
This makes no mention at all of privacy which I think needs to
be there somewhere. Given that Joel is planning to add text on
that to savi-threats I'd be fine if that is just referenced from
here, or even if that text is moved from savi-threats to this
document, and savi-threats could refer to it here. But the
privacy implications of SAVI do need to be covered here too.
(That assumes that Joel's text is as fine as I'm sure it
will turn out to be:-)

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Source Address Validation Improvement Framework) to Informational RFC


The IESG has received a request from the Source Address Validation
Improvements WG (savi) to consider the following document:
- 'Source Address Validation Improvement Framework'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Source Address Validation Improvement method was developed to
  complement ingress filtering with finer-grained, standardized IP
  source address validation.  This document describes and motivates the
  design of the SAVI method.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-savi-framework/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-savi-framework/


No IPR declarations have been submitted directly on this I-D.

I have reviewed the new version and it looks good, but I wonder if this suggested change was missed:

>> 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 ] with or
> without Secure Neighbor Discovery [rfc3971], IKEv2
> [rfc5996,rfc5739,rfc5026] and combinations thereof.

Or perhaps you disagreed with the change. In any case, I can't find a change in the new document or any discussion about this particular issue. Can you take a look?

Nevertheless, I have sent the document forward to a last call.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
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], for
> links with DHCP [rfc2131][rfc3315], for links with Secure Neighbor
> Discovery [rfc3971], for links with IKEv2 [rfc5996] [rfc5739]
> [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] 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.

(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he or she believe this version is ready for
forwarding to the IESG for publication?

Jean-Michel Combes (jeanmichel.combes@gmail.com) is the Document
Shepherd, savi WG co-chair. He has done a review on the document and
believes it is ready to be forwarded to IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have any
concerns about the depth or breadth of the reviews that have been
performed?

The document has had adequate reviews by key WG members.The document
shepherd does not have any concerns regarding the depth or breadth of
the reviews received.

(1.c) Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA,
internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or issues
with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there
really is a need for it. In any event, if the WG has discussed those
issues and has indicated that it still wishes to advance the document,
detail those concerns here. Has an IPR disclosure related to this
document been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on this
issue.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is savi WG consensus behind the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See the Internet-Drafts Checklist and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media type
and URI type reviews?

The document shepherd has personally verified that the document
satisfies all ID nits. The document does not need MIB doctor review.
The document does not contain any media and URI types.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are not
ready for advancement or are otherwise in an unclear state? If such
normative references exist, what is the strategy for their completion?
Are there normative references that are downward references, as
described in [RFC3967]? If so, list these downward references to
support the Area Director in the Last Call procedure for them
[RFC3967].

References are split into normative and informative sections.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the IANA
registries clearly identified? If the document creates a new registry,
does it define the proposed initial contents of the registry and an
allocation procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation?

This document has an IANA considerations section and no IANA
considerations that needs to be taken care of.

(1.j) Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules,
MIB definitions, etc., validate correctly in an automated checker?

There are no such sections.

(1.k) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up? Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary
The Source Address Validation Improvement method was developed to
complement ingress filtering with finer-grained, standardized IP
source address validation. This document describes and motivates the
design of the SAVI method.

Working Group Summary
The normal WG process was followed. The document as it is now,
reflects WG consensus.

Document Quality
The document was thoroughly reviewed by Frank Xia, Mikael Abrahamsson
and Jean-Michel Combes.