Subject: Re: Last Call: draft-wu-sava-testbed-experience (SAVA Testbed and Experiences to Date) to Experimental RFC

From: Jari Arkko <[email-masked]>
Date: Wed, 19 Mar 2008 17:53:59 +0200

Just FYI, this draft is being AD sponsored as a report of a research effort
that certain people have done in the source address validation space. To
quote my ballot explanation:

   This draft documents an experimental design implemented in
   a research network for source address validation. The draft
   is not intended as a solution proposal but rather as a
   report of something that was done together with both
   the positive and negative experiences.

Jari

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Mar 2008 17:37:06 +0200 (EET)

>   the positive and negative experiences.

I've reviewed this draft.  I'm not sure what the draft intends to 
document as it doesn't go into much detail on how they solved 
difficult and more interesting issues, for example:
  - how they solved MTU problems caused by adding hop-by-hop header
  - given their deployment model, why didn't they try inserting a destination options
    header instead of hop-by-hop and if they tried, why it didn't work;
  - how did the rekeying of inter-AS solution work (not described)

These would increase the value of the report.  Even without those, 
publishing the report may be of some value.  However, I object to 
publishing the draft as written. At least issue 1) below needs to be 
fixed before publication because the draft is confusing and 
misrepresentative of the scope of existing solution solution space.

1) Access Network SAV and Intra-AS SAV terminology misrepresents the
applicability of BCP38/84 and needs to be rephrased.

    We use the term "intra-AS source address validation" to mean the IP
    source address validation at the attachment point of an access
    network to its provider network, also called the ingress point.  IP
    source address validation at ingress points can enforce the source IP
    address correctness at the IP prefix level, assuming the access
    network owns one or more IP address blocks.  This practice has been
    adopted as the Internet Best-Current-Practice [RFC2827][RFC3704].

This text (also to some degree the previous paragraph) and Figure 1 
are confusing.  In Figure 1, Intra-AS SAV occurs between two routers 
is construed as if it was only applicable between routers. BCP38 and 
BCP84 are applicable also in scenarios which are in the figure listed 
under "Access Network SAV", not just under intras-AS SAV. 
Specifically, BCP38/84 can be applied on each LAN interface of a 
router.  In case router connects just one host, that is also a 
sufficient solution and nothing else is needed.

The figure needs to be redone.  The mechanisms described for "Access network
SAV" are only useful in contexts where multiple hosts attach to a router
using a single interface (e.g., using a switch).  Otherwise BCP38/84
mechanisms of Intra-AS SAV apply and access network SAV is not necessary.

One way to approach this is to change the figure as follows:

                   __ ____                          __ ____
               .-''       `':                   .-''       `':
               |             |                  |             |
               |   +-+----+  |   Inter-AS SAV   |   +-+----+  |
               |   |Router+--+------------------+---|Router+  +
               |   +--.---+  |                  |   +--.---+  |
    Intra-AS   |      |      |       Intra-AS   |      |      |
       SAV     |   +--+---+   \         SAV     |   +--+---+  |
               |   |Router|    \                |   |Router|  |
               |   +--.---+     \                '_  +-----+  _
               |      |          \                `'-------'''
              /       |           |
             /        |           |
            | +------------------+|
            | |  .-----. Router  ||
            | ++/-------\--------+|
            |  ||     |  |   |    |
            |  ||+------+|+------+|Intra-AS
            |  |||Switch|||Router||SAV
            |  ||+------+|+------+|
            |  ||\_   |  \   |    |
            |+-+--+\+----+|+----+ |
            ||Host|||Host|||Host| |
            `.----+|+----+|+----+,'
              `--. /      |  _.-'
                  `-------+''
                   Access
                   Network
                   SAV

Further, rephrase:

    It is important to enforce IP source address validity at the access
    network.  That is, when an IP packet is sent from a host, the
    routers, switches or other devices should check to make sure that the
    packet carries a valid source IP address.  If this access network
    source address validation is missing, then a host may be able to
    spoof the source IP address which belongs to another local host.

To:

    When multiple hosts attach to the same network, switches could check to
    make sure that the
    packet carries a valid source IP address.  If this access network
    source address validation is missing, then a host may be able to
    spoof the source IP address which belongs to another host in the same
     network.

And:

    We use the term "intra-AS source address validation" to mean the IP
    source address validation at the attachment point of an access
    network to its provider network, also called the ingress point.

To:

    We use the term "intra-AS source address validation" to mean the IP
    source address validation at the attachment point of an access
    network to its provider network, also called the ingress point.
    The first intra-AS validation point is where the LAN attaches to its
    first router.

2) "sibling" etc AS-relations are not defined and the usage is not clear

In Section 2.4, there is text wrt Provider, Customer, Peer and Sibling, but
not definition of each.  Especially "Sibling" may not be intuitively
obvious if you're not familiar with current non-IETF routing table analysis
research.  The text should also spell out that VRGE needs to know the
business relationships of all ASes; in the real world this is an
unacceptable solution.  Does anyone else than VRGE need to use that
AS-relation table mapping?

3) inter-AS automatic rekeying mechanism is not described

    The signature needs to be changed frequently, Although the overhead
    of maintaining and exchanging signatures between AS pairs is not
    O(N^2), but O(N), the traffic and processing overhead increase as the
    number of ASes increases.  Therefore an automatic signature changing
    method is utilized in this solution.

This automatic rekeying method is one of the most interesting pieces of this
solution; is there a reason why it is not described in this testbed report?

4) Text about CERNET2 misrepresents the testbed network

    The prototypes of our solutions for SAVA are implemented and tested
    on CNGI-CERNET2.  CNGI-CERNET2 is one of the China Next Generation
    Internet (CNGI) backbones.

In the interest of truth in advertising, the document should also mention
CERNET.  CERNET2 is a testbed backbone that is not very widely utilized;
I've been told that CERNET2 is not expected supersede the original CERNET
production network.  Maybe: rephrase add to the end of the last sentence:
" that provide testbed facilities to augment existing production backbones
(e.g. CERNET)".

    The
    CNGI-CERNET2 backbones are IPv6-only networks, not a mixed IPv4/IPv6
    infrastructure.  The CNGI-CERNET2 backbones, CNGI-CERNET2 CPNs, and
    CNGI-6IX all have globally unique AS numbers.  Thus a multi-AS
    testbed environment is provided.

CERNET2 was described at IETF64 in Softwire WG meeting
<http://www.ietf.org/proceedings/05nov/slides/softwire-3/sld1.htm>.  It is
not an IPv6-only network; in fact, all customer-facing PE-routers are
dual-stack.  The first sentence above is therefore incorrect and should be
removed.

Alternatively, one could remove entire Section 3.1; it does not appear to be
critical to the readability of the draft.

5) the conclusion appears to be overly generous wrt the results of the draft

    First, the experiment is a proof that a working system can be built
    on the basis of the loosely-coupled domains and "multiple-fence"
    design for source address validation.

Given that none of the new mechanisms tested could be deployed as-is due to
the limitations listed in Section 5, it appears a little bit too generous to
call this a "working system".  Maybe instead:

    First, the experiment is a proof that a prototype can be built that is
    deployable on loosely-coupled domains of test networks in a very limited
    scale and "multiple-fence" design for source address validation.

This also seems too genereous:

    The experiment also provided a proof of concept for the switch-based
    local subnet validation, network authentication based validation,
    filter-based Inter-AS validation, and signature-based Inter-AS
    validation mechanisms.

Specifically, all the clients had to be modified (SARC); the switched needed
to be modified (SAVP), and a server needed to be deployed (SAMS).  While one
could say this is a proof of concept, I don't think this is a PoC for
a solution that could be considered deployable.  Maybe add to the end:

"However, this solution required changes to clients and switched and
addition of a server, and as a result, the concept may not be more widely
applicable."

6) future work listing should be beffed up

I suggest adding to the Future work list in Section 6 also at least:

  o Deployability considerations, e.g. modifiability of switches, hosts, etc.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Fri, 28 Mar 2008 10:46:33 +0200

Thanks for your review, Pekka. A few notes:

> it doesn't go into much detail on how they solved 
> These would increase the value of the report.

This would be very useful addition to the document. Authors?

But note that the overall experience from the specific approach chosen
here was that yes, its possible get it to working, but there are
significant issues both for deployment and for the way the protocol bits
are arranged. Remember that this was an experiment, not a design ready
for standardization. MTU problems are in the list that is in Section 5.3.

> I object to 

Right. This needs to be corrected in the draft.

I am not commenting on the remaining issues, but I expect the authors to
address them in a new revision of their document.

Jari

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Mar 2008 12:09:33 +0200 (EET)

> for standardization. MTU problems are in the list that is in Section 5.3.

A lot of issues are brought up in Section 5 (and elsewhere).  For 
issues noted, for each I'd like to ask quostions such as:
  - was this noticed in the testbed?  how?
  - was the issue relevant in that context; if not, why not?
  - if the issue was noticed, how was it worked around?  which
    approaches worked (in that restricted context), which did not?
  - if the issue was not worked around, what kind of impact not
    doing so had in the testbed and in testing?

I suspect some of the issues listed were addressed in some way (not 
necessarily in a globally applicable way).  For example, wrt MTU 
issues, a statement like "MTU increase was not an issue because the 
transit network provided 9000B MTU" or "Participating hosts were 
manually configured to use 1280B MTU" would have been useful.

So, when reading the report, I find it has basically the following 
kinds of content:
  1) some general overview of the problem space
  2) description of new mechanisms developed
  3) description of the testbed where mechanisms were tested
  4) description of issues to be considered in future work

However, 4) seems to be mainly about 1) and 2); it would have been 
possible to write fundamentally the same draft without any significant 
testbed deployment.  In other words, the experiences from the testbed 
and deployment itself are not extensively captured in the report, and 
as a result it is not obvious how useful the testbed was when 
considering follow-up activities in this space.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 28 Mar 2008 12:15:32 +0200

> For issues noted, for each I'd like to ask quostions such as:
Yes, this would be useful.

Jari