|
Re: Gen-ART LC Review of draft-ietf-tsvwg-ecn-tunnel-08
2010-07-22 09:50:53
Sorry for the late response--I just got back online after being out a few days
for surgery.
Your response addresses my (final) concern.
Thanks!
Ben.
On Jul 16, 2010, at 9:29 AM, Bob Briscoe wrote:
Ben,
At 20:47 14/07/2010, Ben Campbell wrote:
Thanks for the response. Further comments inline. (If I don't comment on a
point, please take that to mean "okay" :-) )
On Jul 13, 2010, at 6:13 AM, Bob Briscoe wrote:
Ben,
Thank you for your review comments from the GEN-ART perspective.
I think I have dealt with all your points in my responses, which are
inline...
There is just one outstanding question for you concerning updating
BCP4774...
At 22:23 01/07/2010, Ben Campbell wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-tsvwg-ecn-tunnel-08
Reviewer: Ben Campbell
Review Date: 2010-07-01
IETF LC End Date: 2010-07-06
IESG Telechat date: (if known)
Summary:
This draft is almost ready for publication as a proposed standard. I have
a couple of procedural questions that should be considered first, as well
as a few editorial comments.
Major Issues: None.
Minor Issues:
-- RFC Editor request (immediately after ToC): "In the RFC index, RFC3168
should be identified as an update to RFC2003.
RFC4301 should be identified as an update to RFC3168."
This seems odd. I assume the intent is that this draft says that things
from 3168 should be applied to 2003, therefore updating 2003, etc? If so,
wouldn't it be more correct to say that _this_ draft updates 2003 and 3168?
Quoting from the RFC Index:
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Updates xxxx refers to other RFCs that this one merely updates but
does not replace); ...
Generally, only immediately succeeding
and/or preceding RFCs are indicated, not the entire history of each
related earlier or later RFC in a related series.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
The consensus on the TSVWG list was that the updates should be identified
in the RFC Index as follows
2003 -> 3168 -> ecn-tunnel
3168 -> 4301 -> ecn-tunnel
In the headers of this draft we have said:
Updates: 3168, 4301
But we also noticed that the RFC Index incorrectly omits to identify that
these RFCs in turn already update the earlier RFCs. The note to the RFC
Editor was the result of this consensus request from the TSVWG list.
[BTW, There is nonetheless text on backward compatibility between this I-D
and these early RFCs in Section 6. And "Appendix A; Early ECN Tunnelling
RFCs" explains the interactions.]
Summary: I propose no change on this point.
It's not entirely clear to me how the RFC index quote supports the argument
one way or another. I was not proposing we needed to maintain the entire
history of updates.
Was the work group consensus that 3168 _already_ updated 2003 (i.e. the
original intent of 3618 was to update 2003), and the notation of that fact
was simply missing? Or that it _should_have_ updated 2003 but did not? If
the first, then I agree with the proposed approach. But if the second, then
I think you have a case of _this_ draft updating 2003 by calling out text in
3618 that should now apply to it.
The first.
Even though section 9 of RFC3168 on updates to tunnel processing
<http://tools.ietf.org/html/rfc3168#section-9>
contained two parallel subsections (9.1 & 9.2) on respectively IP in IP
tunnels referencing 2003 and IPsec tunnels referencing 2401 (IPsec), it only
included 2401 in the "Updates" header. There can be no other explanation than
simple error for omitting "Updates 2003".
In particular, does 3168 contain text on how it updates 2003? Could someone
understand how 3168 applies to 2003 by reading that document alone?
Yes
Or does that text reside in this draft?
No
In any case, if you still believe it should stand as is, I will not push the
point further. If the IESG is okay with the approach, then it's fine with me.
I guess I ought to submit an erratum for RFC3168 and RFC4301 at the same
time, in order to add these two "Updates" headers.
-- 7, first paragraph: "The guidance below extends RFC4774, giving
additional guidance on designing any alternate ECN semantics
that would also require alternate tunnelling semantics."
Should this draft be listed as updating 4774? Also, you've declared this
section non-normative. What does it mean to non-normatively extend a BCP?
That's a very good question/point and I would appreciate your advice on how
to proceed. My take was that this was an informational section of a STDS
RFC. So I did not include any RFC2119 language. But your nicely succinct
question throws this into better perspective.
Should I:
* Add 'Updates 4774' to the headers?
* Scrub the line saying "This section is informative not normative." ?
* Shift the RFC2119 keywords in this section to upper-case?
See my response to your separate email on this subject.
Nits/Editorial:
-- General:
[...]
-- 5.3.1, last bullet:"… the IETF Security Area now considers copying
acceptable given the bandwidth of a 2-bit covert channel can be managed."
Can you supply a reference for that assertion?
1. Introduction
already says:
"...Nonetheless, the latest IPsec architecture [RFC4301] considered a
bandwidth limit of 2 bits per packet on a covert channel made it a
manageable risk."
It's a subtle distinction, but I'm not sure the fact that 4301 says it's
okay necessarily represents any specific current belief on the part of the
Security Area (But I guess the security ADs can decide that.) But given that
such believes can change over time, and an RFC is fixed, perhaps it would be
better to simply repeat the mention that 4301 asserts this.
BTW, a quick perusal of 4301 seems to say something more to the effect of
"administrators can decide if the risk is acceptable" rather than "the risk
is acceptable". When you say the risk is "manageable", are you referring to
the fact an administrator could "manage" it by turning copying off?
ecn-tunnel has just been through SECDIR review (unscathed) precisely to
ensure this belief still holds. I also presented this draft in the Security
Area open meeting a couple of IETFs ago to try to flush out any objections
(none received), and requested objections on the ipsec mailing list (none
received).
RFC4301 is zero-config with regard to ECN. There is no standards provision
for turning anything ECN-related off or on.
I can't find your quotes above so I assume they are paraphrases. I think you
are referring to the para below, which says IPsec provides the ability to
control propagation of changes in ECN and DS. But 4301 only provides config
for DS propagation. At an early stage I also checked the ipsec ml discussion
from the time, and it was very clear that they wanted ECN to be zero-config
and that was how it would be.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
o IPsec describes how to handle ECN or DS and provides the ability
to control propagation of changes in these fields between
unprotected and protected domains. In general, propagation from a
protected to an unprotected domain is a covert channel and thus
controls are provided to manage the bandwidth of this channel.
Propagation of ECN values in the other direction are controlled so
that only legitimate ECN changes (indicating occurrence of
congestion between the tunnel endpoints) are propagated.
[...continues discussion, but wrt DSCP only]
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Thanks for checking all these aspects - but I'm pretty sure I had already
done my due diligence in these respects.
Bob
[...]
________________________________________________________________
Bob Briscoe, BT Innovate & Design
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|