[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[savi] about draft-vogt-savi-rationale-00.txt



Hi Christain,

i think the document is a very good starting point to document the desig choices we are making. Some comments below...

The abstract reads:

  The IETF working group on Source Address Validation Improvements,
  SAVI, is chartered to design methods for IP source address validation
  that complement ingress filtering with finer-grained protection.

Not that i am disagreeing here, but it seems from the phrasing that this was decided in the charter, while i understand that the choice of relying on ingress filtering was a design choice made by the wg i.e. it ia conclusion rather than a starting point.

Later on,

3.  Packet Classification

  The prerequisite that a SAVI solution should be complementary to
  ingress filtering, and not substitute it, implies that SAVI should
  not validate packets that are forwarded by routers.  This calls for a
  method for SAVI to classify first-hop packets from forwarded packets
  (where "first-hop packets" are transmitted by the originating host,
  and "forwarded packets" are relayed by a router).  Techniques to
  achieve such packet classification can be divided into the following
  classes:

  1.  Packets are classified based on whether or not their source
      address is from an on-link subnet prefix.

  2.  Packets are classified based on whether or not the sending node
      is an authorized router.


i think that in any case we need both.
I mean, we need the list of onlink prefixes, if not SAVI does not know which source addresses can be generated by onlink nodes We need the list of routers cause if not we don't know which of the directly connected devices can generate packets with off-link source addresses.

I am don't see how you can build a savi solution with only one of those
I don't see these as one or the other, but i think you need one _and_ the other.

Besides, i found the following typos in the document (perform a search for these)

scurity
EIn
EOr


Regards, marcelo



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.