Thanks for your review, Pekka. A few notes:
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.
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
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.
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
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf