A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience
draft-wu-sava-testbed-experience-06

[Ballot comment]
I like the idea of such documents and the document itself - documenting the implementation and deployment of a proof-of-concept prototye of new solutions is very useful and I like to see more of such documents based on code and experimentation in real networks showing uo in the IETF.

I would suggest a change in the title of the document. Instead of 'SAVA Testbed and Experiences to Date' which seems to be rather exhaustive (after all the SAVA concepts and architecture have been dicussed for a while and no absolute claims can be made that other experiments do not exist to date) I would rather suggest something like 'A SAVA Testbed and Deployment Experience'.

[Ballot comment]
I like the idea of such documents and the document itself - documenting the implementation and deployment of a proof-of-concept prototye of new solutions is very useful and I like to see more of such documents based on code and experimentation in real networks showing uo in the IETF.

I would suggest a change in the title of the document. Instead of 'SAVA Testbed and Experiences to Date' which seems to be rather exhaustive (after all the SAVA concepts and architecture have been dicussed for a while and no absolute claims can be made that other experiments do not exist to date) I would rather suggest something like 'A SAVA Testved and Deployment Experience'.

[Ballot comment]
I'm a little disappointed that the document focuses so much on describing the design of the testbed system as well as various other design options, deployment considerations, etc. I had hoped to see some hard measurement data gathered during the experiment that would quantify system behavior and performance. Instead, the document just says "all worked as expected."

[Ballot comment]
Please remove references from the abstract (i.e., [Wu07]).

  Section 1: s/accomplishedaccurately/accomplished accurately/

  Figure 5: s/.REG/REG/

  Section 5.2 describes future work being considered for less stable
  network environment.  More details about key management and the
  cryptographic algorithm are needed for that work to go forward.
  Perhaps that is left to a future document.

Looks reasonably OK based on quick review; at least major LC comments have been taken into account. Maybe the writing could be better, and I wish the document had more beef, and even more warning signs. But ...

And many thanks for the new draft version! The new draft
is a truly significant improvement from the previous one and
we are now very close to sending this forward to IETF Last
Call.

However, a number of small issues, a couple of missing
explanations, and one bigger issue remains. Please see
below for the details.

I do expect that the changes to the document are relatively
small, and you should be able to respin it in a matter of days.

Figure 2 or the text does not explain the acronym ABSR.
Suggested edit:

OLD:
Key: AIMS == AS-IPv6 prefix Mapping Server, VRGE == Validation Rule
Generating Engine, VE == Validating Engine
NEW:
Key: AIMS == AS-IPv6 prefix Mapping Server, VRGE == Validation Rule
Generating Engine, VE == Validating Engine, ASBR = AS Border Router

Is the AER in the next Section the same kind of entity as the ASBR?

> This
>    particular method uses a light-weight signature.
Please add a few sentences about what the signature is where
it is carried in the packet.

>    world), not the mixed IPv4/IPv6 infrastructure.  The CNGI-CERNET2
... not a mixed ...


Section 2.4 and 2.5 both need a paragraph at the beginning
that explains what the scheme is. I understand this, but
only because I already know what you are doing.

>    o When the member list is changed, notifiy each AS Control Server.
s/notifiy/notify/

>    3.  For the Inter-AS (non-neighboring AS) SAVA solution, the
>        validation function is implemented by software in a layer-two box
>        running Linux.  During the test, If the box connected directly,
>        it can achieve a normal forwarding line speed.  If the box is
>        connected with devices from other vendor, it can only achieve a
>        very limited line speed.  The reason is that the signatures are
>        added on the IPv6 hop-by-hop option header and the network device
>        from vendors handled the hop-by-hop options just by software.
>
s/box/device/g

> 5. Design Limitation


This section still needs work. I agree with everything stated here, but
as the purpose of the draft is to convey experience, I'd like to see
more of that experience listed here. In addition, for balance you need
to talk about all the potentially negative aspects, too.

Here's a start:

- The size of the packets increases with the signatures

- Its not clear that the IPv6 hop-by-hop options is the right
  tool for the task. For instance, this option has to be looked at
  by all intervening routers.

- The addition of the option and the calculation of the signature
  can consume valuable resources on the forwarding path; given
  that core routers are already suffering from complex tasks
  (large routing tables, deep packet inspection) it can be asked
  whether adding more tasks to the critical path is wise.

- Similarly, it is unclear whether the lack of universal deployment
  of source address validation is a technical issue that needs a
  technical solution, or if mere further deployment of existing
  tools (such as BCP 38) would be a more cost effective way
  to improve the situation. Further deployment efforts of this
  tool have proved to be slow, however.

- Deploying the test system in the global Internet would face
  significant coordination and key negotiation issues, given the
  number of ASes.

- Deploying new mechanisms for ensuring correctness of
  addresses in local subnet may lead to interoperability
  problems, if hosts require new code to acquire addresses.

- Local subnet verification mechanisms that do not rely on the co-operation
  of a switch or per-packet cryptographic protection are generally hard to
  make secure; attackers may pretend to use the IP and link layer addresses
  of legitimate hosts.

- Given that a large fraction of current denial-of-service attacks are
  employing legitimate IP addresses belonging to botnet clients, even
  universal deployment of better source address validation techniques
  would be unable to prevent these attacks. However, tracing these
  attacks would be easier given that there would be more reliance
  on the validity of source address.

I have reviewed an early version -02, and provided comments back to authors. A new revision is still needed:

Overall comments:

- I think we make this a good experimental RFC, but
  more work is needed.

- You need to fold in more of the explanation of what you
  are doing. I'm sure the text exists in other drafts and
  documents already, so it should not be too hard.

  The document needs to contain a description of the
  problem that you intend to solve, a description of
  your solution at an appropriate abstraction level,
  a description of what you implemented and how
  (this part is well in the document already), and
  the experiences.

  Your goal should be that this document can be
  read in isolation, and a person who understands
  IP networks will understand what problem you are
  solving, roughly how you did it, and what your
  experiences are.

- I would consider whether some aspects of the
  framework of solutions need to be dropped for
  readability. For instance, you could only focus on
  the solutions that Sections 3.2 and 3.3 talk about,
  but not the rest.

- Current Section 4 has way too much detail, and
  is not very interesting material for some outsider
  later reading the RFC. I would recommend deleting
  Section 4 entirely and merely summarizing the type
  of tests run on it in a paragraph or two in Section 5.

- Section 5 is good, but needs more material.

- Some other smaller issues noted as I reviewed the
  document.

Details:

> > 1.  Introduction

This should be rewritten to briefly describe what the overall
problem is, so that the problem is clear without reading the
references. Please remember that draft references in an
RFC will eventually not be very useful; the RFC should be
fairly self-contained and contain references only for the
purpose of acknowledging other work etc, not for explanation
of key issues.

I would also avoid talking about the framework in this
document. Just talk about what problems you are addressing
and the set of tools you used in your experiment to counter
them.

I liked the 2nd paragraph.

> >                      Figure 1: SAVA Framework Layers

Abbreviations (such ASBR) appear in this figure without
having been previously explained, or even explained in
the context of introducing the figure.

You also need to explain the layers. Maybe this can go
into the introduction, or in Section 2.

> > Figure 4, 5:

I'm not sure these add value. Please also remove some
of the names in any of the figures, if they are commercial.
E.g., is zebra just a dns name or a vendor? Not sure we
need to see the IP addresses or As numbers either, unless
they are used in examples later on.

> > 2.2.  SAVA Testbed on CERNET2 Infrastructure

Please spend some time explaining more about the
Tsinghua network and what it does. I.e., figures alone
are insufficient.

> > Providor
Provider

> >  Checking nits according to http://www.ietf.org/ID-Checklist.html:

These idnits issues should be corrected. (Test at
tools.ietf.org/tools/idnits)

Note: the addresses may or may not be OK as they are. *If* they make sense
to be included in the RFC, they may be better as the real addresses that you
used than fake ones. But I'm not sure they are needed to explain what
you are doing.

> >              Figure 8: AS-Relation Based Inter-AS Filtering

I don't understand this table or the explanation. It could
be just the fact that I have not read [Gao], but I suspect
other readers would have similar problems.


> >    The Registration Server is the "center" of the trust alliance (TA) .
> >    It maintains a member list for the TA.  It performs two major
> >    functions:
> >
> >    o Processes requests from the AS Control Server, to get the member
> >    list for the TA.
> >
> >    o When the member list is changed, notifiy each AS Control Server.

Something funny in the indentation of the bullet lists. Its
hard to read.

> > 192.168.1.2

Why do we have IPv4 addresses in the document if your solution
is for IPv6?

> > 4.1.  Inter-AS (non-neighboring) SAVA Solution Test
> >
> > 4.1.1.  TsingHua University Inner Test
> >
> > 4.1.1.1.  Tag Signature Test
> >
> > 4.1.1.1.1.  Test Content

Please. No nesting this deep...  :-)

> > 4.1.1.1.1.  Test Content

We have to talk about what information is useful for the reader.
The above description would fit better a university report series,
or a software test manuals.

When we talk about IETF experimental RFCs, the readers are interested
in higher level issues, such as:

- How did you test this -- what the network architecture was, maybe
  even a list of test cases, but NO details about the test cases

- How your implementation was structured, e.g., there was some
  good text earlier about the separation of the impementation to
  the verification parts and the server holding the AS-prefix
  mappings.

- What were the difficult parts in the implementation?

- What were the good / bad properties of the solution (as a desk
  exercise)?

- Good / bad properties (through your experiences when using
  this)

Etc. I.e., things that the reader can learn from, not things that
someone would need if they wanted to unit test your system.

> > 5.  Testbed Conclusion

Good stuff, but we need more. See the above list for possible
ideas. You could also talk about some of the bad things
we know the signature scheme and its encoding has; I think
we all agree that its just a prototype version.

The goal should be that there are at least a few pages of
experience like this.

> > 9.1.  Normative References
> >
> >    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
> >              Requirement Levels", BCP 14, RFC 2119, March 1997.

Not needed.

Where's BCP 38 reference?