General nit - asking for comments to be sent to a project specific
mailing list is annoying when it is required to be subscribed in
order to send email to the list. This is more of an opensolaris
problem (sending to the unsubscribed lists), but I'm none too
pleased about being expected to subscribe to another forum
to reply to email sent in one I already subscribe to. Therefore
my comments will be going to networking-discuss.
Dan McDonald wrote:
Pardon my last incorrect URL. The IPsec Tunnel Reform design document:
http://www.opensolaris.org/os/project/tref/tunnel-reform.pdf
has a review expiration date of Wednesday July 26th at 23:59
US/Eastern time.
This is a reminder of that date and time.
General - "also" is overused. Think about using "in addition" in
some cases, to make it seem less repetitive/regurgitated.
Also, the lack of section numbering makes it hard to properly
cite an area of the document to refer to in comments.
Section: Overview
"...with other implementions if..."
if -> of
Section: Problem Statement
The first paragraph is confusing. I think what you're trying to say is
that with Solaris8, encrypted IP tunnels were configured jointly with
ifconfig (encr_algs/auth_algs) as well as IPsec, rather than just IPsec.
I've never heard of the term "Secure IPv4 tunnels" before, and it made
me think these were some kind of special tunnel, but I suspect they're
not.
Where it starts "Also, the IKE daemon...", consider introducing the
IKE daemon as a problem but specifying that it is non-standard in the
follow on paragraph where you talk about the Solaris behaviour.
The paragraph beginning "Furthermore, the newest.." needs some
attention. The text "also still specifies" seems...wanting, plus there
are two sentences that are effectively "IKEv2 also...". In addition,
you should say "hereafter referred to in this document as 430x".
Section: Goals and Non-Goals
What do we gain from just severely reducing the problems?
If in the interest of time and effort achieving full interoperability
with all of the listed targets isn't possible, break the list up into
sets, such as "must/should/be nice to" be interoperable with.
The problem statement mentions RFC 2409 but 2401 is mentioned
here. Why is fixing 2409 a goal if it isn't a problem? And vice versa.
Section: Concepts
The second paragraph. Who is it that hasn't agreed on something?
There seems to be a joining together of three parties here and it
isn't quite clear how all three would communicate to each other.
Where you have "tunnel mode -> it merely", consider using a ":" in
place of the "->".
The acronym "SADB" has already been introduced, in the Overview.
This paragraph reads like it belongs in the Problem statement?
Following this, "One suggestion 3884...", consider changing to
"Another...".
The document says "This project will not implement..." - what are the
implications of this choice? Or is there no choice here, for us, given
the history of IPsec in Solaris? Can it be addressed in the future?
I suspect that this choice is a result of the drawback mentioned before
it, if so, maybe write it as "As a result, this project will not..."
Section: Internal Data Structure Changes
The acronyn SPD has already been introduced.
The topmost level of what abstraction is the Policy Head?
The implementation of the rules is given as a single linked list,
I imagine this is because the list of selectors is more than just
IP addresses?
Why is the acronym ITP introduced with ", or ITP,", rather than
with the more traditional ()'s?
The word "make" should be plural in "implementation make changing".
Why is "Tunnel Fragment Cache" mentioned in a section of changes
when there obviously are none to make or mention?
Consider introducing the acronym "SA" in the Overview so that you
don't need to write "security association (SA)" - it looks strange to
see an acronym introduced for two words that aren't capitalised.
Section: Internal Packet Processing Changes
Which IP policy(s) will the tunnel mode become involved in?
For IPSEC_OUT/IPSEC_IN metadata, how is this tagged on to
a packet? Is this described in another document (citation if
so, please)?
Where you begin a sentence with "but the FireEngine project...",
it seems like you should be making a conclusion after this but none
is made? Is the lack of eliminating handling IPSEC_OUT/IN a good
thing or bad?
Are there any changes to the IPsec transport code paths?
Cheers,
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
