Sorry for the long delay in responding. I am updating the draft now.
I have added specific references to OSPFv3 and mentioned ISIS for IPv6
explicitly, since both should work without issue.
On 6/4/06, Pekka Savola <[email protected]> wrote:
On Sun, 4 Jun 2006, Alex Zinin wrote:
>> Further than that, it seems that additional words are possibly needed about
>> multi-topology IS-IS (and maybe the multi-topology OSPF)?
> Unless someone would like to suggest actual text, I wouldn't go after this
> as an important goal. We can always address this in a separate document.
As we don't use multi-topology ourselves, I'm fine with that provided
that those being out of scope is clearly stated in the document(s).
I have added the following to indicate that they are out of scope.
"The applicabilty and interactions of LFAs with multi-topology OSPF
[I-D.ietf-ospf-mt] [I-D.ietf-ospf-mt-ospfv3] is out of scope for this
"The applicability and interactions of LFAs with multi-topology ISIS
[I-D.ietf-isis-wg-multi-topology is out of scope for
I'm not certain that substantial issues are raised; the computation
for alternates would be per topology, but there might be some special
>> This specification defines a form of SRLG protection limited to those
>> SRLGs that include a link that the calculating router is directly
>> connected to. Information about local link SRLG membership is
>> manually configured. Information about remote link SRLG membership
>> is dynamically obtained using [RFC4205] or [RFC4203].
> ==>> the last sentence seems a bit assumptive. Is it assumed that to be able
>> to use _IP_FRR with SRLG, you'll need to deploy GMPLS and TE extensions for
>> your IGP? Maybe more leeway is needed here (e.g., the above references are
>> just examples of remote SRLG information sources).
> We can say "may be obtained".
That's be good.
>> 7. Security Considerations
>> The mechanism described in this document does not modify any routing
>> protocol messages, and hence no new threats related to packet
>> modifications or replay attacks are introduced. Traffic to certain
>> destinations can be temporarily routed via next-hop routers that
>> would not be used with the same topology change if this mechanism
>> wasn't employed. However, these next-hop routers can be used anyway
>> when a different topological change occurs, and hence this can't be
>> viewed as a new security threat.
> ==>> Do the LDP usage case requirements set down by this spec cause security
>> considerations (they certainly cause propagation of information throughout
>> the domain)? Maybe this needs a brief mention here, and possibly
>> appropriate pointers if these modes have been adequately described in an LDP
> Could you be more specific as to what you think may become a new security
I was referring to section 5:
This means that a Label Switched Router (LSR) running LDP must
distribute its labels for the FECs it can provide to all its
neighbors, regardless of whether or not they are upstream.
Additionally, LDP must be acting in liberal label retention mode so
that the labels which correspond to neighbors that aren't currently
the primary neighbor are stored. Similarly, LDP should be in
downstream unsolicited mode, so that the labels for the FEC are
distributed other than along the SPT.
.. I don't really know LDP at all, but this brings a couple of
concerns which a more LDP-savvy person can probably address if
- does distributing labels for all the neighbors or other than
along the SPT pose a risk ("exposing data about FECs wider than
The information is to trusted neighbors with whom an LDP session has
already successful been established.
- does such wider distribution also imply wider modification of label
information (if label distribution if hop-by-hop instead of
I'm not sure what you mean by this?
- does "liberal label retention mode" cause impact, e.g., allow a
neighbor hijack or listen to labeled traffic?
No - the "liberal label retention mode" simply means that a router
should store the most recent label advertisements, even if the router
isn't planning on using it immediately.
If I'd have to guess, I'd say the main difference is likely that label
information is distributed rather widely, and such information could
be sensitive. But if the whole network is equally trusted, this might
not be an issue.
That's my thought.
Even if there was no issue with this, I'd say explicitly something
like: "In LDP, wider distribution of FEC label information and a more
liberal label acceptance is believed to have no significant security
In general, I believe that liberal label mode is normally used. I
will add the following to the draft.
"In LDP, the wider distribution of FEC label information is still to
neighbors with whom a trusted LDP session has been established. This
wider distribution and the recommendation of using liberal label
retention mode are believed to have no significant security impact."
rtgwg mailing list