On Wed, 19 Mar 2008, Jari Arkko wrote:
> 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.
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
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf