[email protected]
[Top] [All Lists]

Re: comments on IPFRR drafts

Subject: Re: comments on IPFRR drafts
From: Pekka Savola
Date: Mon, 5 Jun 2006 09:32:28 +0300 EEST
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).
    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 necessary:
 - does distributing labels for all the neighbors or other than
   along the SPT pose a risk ("exposing data about FECs wider than

 - does such wider distribution also imply wider modification of label
   information (if label distribution if hop-by-hop instead of

 - does "liberal label retention mode" cause impact, e.g., allow a
   neighbor hijack or listen to labeled traffic?

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.
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
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>