On 05/12/18 17:34 , Spencer Dawkins at IETF wrote:
Hi, Acee,
On Tue, Dec 4, 2018 at 6:37 PM Acee Lindem (acee) <[email protected]
<mailto:[email protected]>> wrote:
Hi Spencer,
I'm replying as document shepherd.
It's a pleasure to be talking when we're not both sleepwalking on a 777 :-)
Please note that all of these are comments, so covered under "do the
right thing".
On 12/4/18, 1:40 PM, "Spencer Dawkins"
<[email protected]
<mailto:[email protected]>> wrote:
Spencer Dawkins has entered the following ballot position for
draft-ietf-ospf-ospfv3-segment-routing-extensions-20: No Objection
When responding, please keep the subject line intact and reply
to all
email addresses included in the To and CC lines. (Feel free to
cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
The Introduction would have been much clearer for me if these
paragraphs were
much closer to the top of the section - they're at the bottom
of the section
now.
This draft describes the OSPFv3 extensions required for Segment
Routing with MPLS data plane.
Segment Routing architecture is described in [RFC8402].
Segment Routing use cases are described in [RFC7855].
With that change, I'm not sure how much of the discussion in
the Introduction
would still be required, but do the right thing, of course.
I'd make the same suggestion for the Abstract,
Segment Routing (SR) allows a flexible definition of
end-to-end paths
within IGP topologies by encoding paths as sequences of
topological
sub-paths, called "segments". These segments are advertised
by the
link-state routing protocols (IS-IS and OSPF).
This draft describes the OSPFv3 extensions required for Segment
Routing with MPLS data plane.
if it was more than two paragraphs long ...
You mean "were" since this is subjective. I'm not sure what you're
asking for since your comment has something to do with ordering and,
as you note, the abstract is two paragraphs long.
Sorry this wasn't clear.
What I meant was, the Introduction is long enough that moving the
high-order bits to the top is helpful; the Abstract also has the
high-order bits at the bottom, but it's a short distance to the bottom.
If you flipped the Abstract, that might be helpful, and would match the
Introduction, but if you don't, I think making the change in the
Introduction would be sufficient.
ok, I made the change to Introduction section
I am thinking that the reference
There are additional segment types, e.g., Binding SID defined in
[RFC8402].
would be more useful at the beginning of Section 3, because
that's where you
list the additional segment types, but the reference is back in the
Introduction (with only one example of the segment types).
Actually, the Binding SID is no longer in the encodings so this
could be removed.
An even better reason to remove this sentence :D ...
That would put the reference to RFC 8402 in Section 3, I assume.
I removed both references to binding SID.
thanks,
Peter
I'm thinking the SHOULD in this text
Existing security extensions as described in [RFC5340] and
[RFC8362]
apply to these segment routing extensions. While OSPFv3 is
under a
single administrative domain, there can be deployments where
potential attackers have access to one or more networks in
the OSPFv3
routing domain. In these deployments, stronger authentication
mechanisms such as those specified in [RFC4552] or [RFC7166]
SHOULD
be used.
is not an RFC 2119 SHOULD that describes interworking, so
something like
In these deployments, stronger authentication
mechanisms such as those specified in [RFC4552] or [RFC7166] are
needed.
I'll defer to our AD, Alvaro. We have normative text in other
"Security Considerations" sections.
Oh, sure. That wasn't my heartburn at all. My point was
would be better, but if this IS a SHOULD, I'm curious why you
wouldn't use
stronger authentication mechanisms if they're needed. You might
want to add
guidance about that, so it's not confused with MUST (BUT WE
KNOW YOU WON'T) as
defined in https://tools.ietf.org/html/rfc6919#section-1.
that I'm reading the text as saying "you're more vulnerable to
attackers, so you SHOULD use stronger authentication mechanisms, but you
might not, for reasons left to the implementer". Is there a reason that
you might decide not to use stronger authentication mechanisms when
you're more vulnerable to attackers? If so, you might provide it as an
example, so the implementers can do the right thing.
(I spent enough time in the SIP community talking to product managers
who wanted to pay for MUSTs, but didn't think they needed to pay for
SHOULDs, that I'm perhaps overreacting to a problem you folks in RTG
don't have. Do the right thing, of course!)
Is there another document that says things like
Implementations MUST assure that malformed TLV and Sub-TLV
defined in
this document are detected and do not provide a
vulnerability for
attackers to crash the OSPFv3 router or routing process.
Reception
of a malformed TLV or Sub-TLV SHOULD be counted and/or
logged for
further analysis. Logging of malformed TLVs and Sub-TLVs
SHOULD be
rate-limited to prevent a Denial of Service (DoS) attack
(distributed
or otherwise) from overloading the OSPFv3 control plane.
? This doesn't seem very SR-specific, although I'm guessing. If
there's a
broader document, I don't object to including this guidance
here, but adding a
reference to a broader document might be useful.
We do have similar text in section 5 of RFC8362. However, it is not
in the "Security Considerations" and the statement about
rate-limiting is not there. It doesn’t hurt to repeat it and it
provides confidence that "security" has been appropriately
"considered".
Agree, and thanks for considering all my comments.
Spencer
Thanks,
Acee
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
