Re: [savi] WGLC: draft-ietf-savi-framework-02

["Jun Bi" <[e-mail]>]

A new version will be delivered soon by taking comments in WGLC.

thanks,
Jun

-----原始邮件----- 
From: Jean-Michel Combes
Sent: Monday, February 28, 2011 10:13 PM
To: SAVI Mailing List
Cc: Christian Vogt
Subject: Re: [savi] WGLC: draft-ietf-savi-framework-02

<WG chair hat off>

Please find my review of this draft below (my comments are mostly
minor/editorial ones):


            Source Address Validation Improvement Framework
                      draft-ietf-savi-framework-02

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.

[snip]

1.  Introduction

   Since IP source addresses are used by hosts and network entities to
   determine the origin of a packet and as a destination for return
   data, spoofing of IP source addresses can enable impersonation,
   concealment, and malicious traffic redirection.  Unfortunately, the
   Internet architecture does not prevent IP source address spoofing.

<JMC>
Maybe, add a reference to the treats doc
[draft-ietf-savi-threat-scope] at the end of the sentence.
<JMC>

   Since the IP source address of a packet generally takes no role in
   forwarding the packet, it can be selected arbitrarily by the sending
   host without jeopardizing packet delivery.  Extra methods are
   necessary for IP source address validation, to augment packet
   forwarding with an explicit check of whether a given packet's IP
   source address is legitimate.

   IP source address validation can happen at different granularity:
   Ingress filtering [BCP38], a widely deployed standard for IP source
   address validation, functions at the coarse granularity of networks.
   It verifies that the prefix of an IP source address routes to the
   network from which the packet was received.  An advantage of ingress
   filtering is simplicity:  The decision of whether to accept or to

<JMC>
s/"is simplicity:  The decision of"/"is simplicity:  the decision of"
<JMC>

   reject an IP source address can be made solely based on the
   information available from routing protocols.  However, the

<JMC>
"information available from routing protocols": maybe add a reference to 
RFC3704
<JMC>

   simplicity comes at the cost of not being able to validate IP source
   addresses at a finer granularity, due to the aggregated nature of the
   information available from routing protocols.  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.  Partial
   solutions [BA2007] exist for finer-grained IP source address
   validation, but are proprietary and hence often unsuitable for
   corporate procurement.

[snip]

3.1.  IP Address Assignment Methods

   Since the SAVI method traces IP address assignment packets, it
   necessarily needs to incorporate logic that is specific to particular
   IP address assignment methods.  However, developing SAVI method
   variants for each IP address assignment method is alone not
   sufficient, since multiple IP address assignment methods may co-exist
   on a given link.  The SAVI method hence comes in multiple variants:
   for links with Stateless Address Autoconfiguration, for links with
   DHCP, for links with Secure Neighbor Discovery, and for links that
   use any combination of IP address assignment methods.

<JMC>
Maybe add a reference for each IP address assignment method.
Maybe, even if this is out of scope from the WG charter, add IKEv2
[RFC5996][RFC5739] as IP address assignment method. I have especially
in mind Mobile Node's Home Address assignment based on IKEv2
[RFC5026].
<JMC>

   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

<JMC>
s/"common case:  Many link deployments"/"common case:  many link 
deployments"
<JMC>

   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.



[snip]


4.  Scalability Optimizations

   The preference to locate a SAVI instance close to hosts implies that
   multiple SAVI instances must be able to co-exist in order to support
   large links.  Although the model of the SAVI method is independent of
   the number of SAVI instances per link, co-existence of multiple SAVI
   instances without further measures can lead to higher-than-necessary
   memory requirements:  Since a SAVI instance creates bindings for the

<JMC>
s/"memory requirements:  Since a SAVI instance creates"/"memory
requirements:  since a SAVI instance creates"
<JMC>

   IP source addresses of all hosts on a link, bindings are replicated
   if multiple SAVI instances co-exist on the link.  High memory
   requirements, in turn, increase the cost of a SAVI instance.  This is
   problematic in particular for SAVI instances that are located on a
   switch, since it may significantly increase the cost of such a
   switch.

[snip]

   In the example of figure Figure 1, the protection perimeter
   encompasses one of the legacy switches, located in the middle of the
   depicted link topology.  This enables a single, unpartitioned
   protection perimeter.  A single protection perimeter minimizes memory
   requirements for the SAVI instances because every binding is kept
   only once, namely, by the SAVI instance that attaches to the host
   being validated.  Excluding the legacy switch from the protection
   perimeter would result in two smaller protection perimeters to the
   left and to the right of the depicted link topology.  The memory
   requirements for the SAVI instances would then be higher:  Since IP

<JMC>
s/"then be higher:  Since IP"/"then be higher:  since IP"
<JMC>

   source address validation would be activated on the two ports
   connecting to the legacy switch, the SAVI instances adjacent to the
   legacy switch would replicate all bindings from the respectively
   other protection perimeter.  The reason why it is possible to include
   the legacy switch in the protection perimeter is because the depicted
   link topology guarantees that packets cannot enter the protection
   perimeter via this legacy switch.  Without this guarantee, the legacy
   switch would have to be excluded from the protection perimeter in
   order to ensure that packets entering the protection perimeter
   undergo IP source address validation.


5.  Reliability Optimizations

[snip]

   To limit the disruption that missing bindings for legitimate IP
   addresses can have, the SAVI method includes a mechanism for reactive
   binding creation based on regular packets.  This mechanism
   supplements the proactive binding creation based on IP address
   configuration packets.  Reactive binding creation occurs when a SAVI
   instances recognizes excessive drops of regular packets originating
   from the same IP address.  The SAVI instance then verifies whether
   said IP address is unique on the link.  How the verification is
   carried out depends on the IP address configuration method that the
   SAVI instance supports:  The SAVI method variant for Stateless

<JMC>
s/"SAVI instance supports:  The SAVI method variant"/"SAVI instance
supports.  The SAVI method variant"
<JMC>

   Address Autoconfiguration and for Secure Neighbor Discovery verifies
   an IP address through the Duplicate Address Detection procedure.  The
   SAVI method variant for DHCP verifies an IP address through a DHCP
   Lease Query message exchange with the DHCP server.  If verification
   indicates that the IP address is unique on the link, the SAVI
   instance creates a binding for the IP address.  Otherwise, no binding
   is created, and packets sent from the IP address continue to be
   dropped.


6.  Mix Scenario

   While multiple assignment methods can be used on the same link, the
   SAVI device may have to deal with a mix of binding discovery methods.
   if the address prefix used for each assignment method is different,

<JMC>
s/"if the address prefix used for each assignment method"/"If the
address prefix used for each assignment method"
<JMC>

   mix scenario can handle the same as scenario with only one assignment
   method.  If different address assignment methods are used to assign
   addresses from the same prefix, additional considerations are needed
   because one binding mechanism may create a binding violating an
   existing binding from another binding mechanism, e.g., binding from
   SAVI-FCFS may violate binding from SAVI-DHCP.  Thus, the collision

<JMC>
Maybe, add references for SAVI-FCFS and SAVI-DHCP.
<JMC>

   between different SAVI mechanisms in mix scenario must be handled in
   case more than one address assignment method is used to assign
   addresses from the same prefix.

[snip]

<JMC>
A Security Considerations section is missing.
An IANA Considerations section is missing too.
<JMC>


[snip]


8.  References

<JMC>
The References section must be split into an Informative References
section and a Normative References section.
<JMC>

   [BA2007]  Baker, F., "Cisco IP Version 4 Source Guard", IETF Internet
             draft (work in progress), November 2007.

   [BCP38]   Paul, P. and D. Senie, "Network Ingress Filtering:
             Defeating Denial of Service Attacks which employ IP Source
             Address Spoofing", RFC 2827, BCP 38, May 2000.

[snip]


Best regards.

JMC.


2011/2/25 Jean-Michel Combes <[e-mail]>:
> Folks,
>
> only 4 days before the end of this WGLC and no feedback for the moment ...
>
> This document is important for the WG:
> - all solutions will have to be compliant with it
> - without feedback, it will be impossible to move forward it (i.e. AD
> review, IESG review)
> - the consequence is that it will be impossible to move forward the
> solutions specs
>
> So, please, review it (it's a short document, only 12 pages) and send
> your opinion on the ML.
>
> Thanks.
>
> Christian & Jean-Michel.
>
>
>
> 2011/2/16 Jean-Michel Combes <[e-mail]>:
>> Folks,
>>
>> This is a 2 weeks working group last call for the "Source Address
>> Validation Improvement Framework" document.
>> Please, don't hesitate to review the draft and to say whether you are
>> in favor advancing the draft or not.
>>
>> Thanks.
>>
>> Christian & Jean-Michel.
>>
>
_______________________________________________
savi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/savi