[email protected]
[Top] [All Lists]

Re: comments on IPFRR drafts

Subject: Re: comments on IPFRR drafts
From: mike shand
Date: Mon, 11 Dec 2006 10:19:37 +0000
At 01:22 09/12/2006, Alia Atlas wrote:
Pekka,

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
specification."

"The applicability and interactions of LFAs with multi-topology ISIS
[I-D.ietf-isis-wg-multi-topology is out of scope for
this specification."

 I'm not certain that substantial issues are raised; the computation
for alternates would be per topology, but there might be some special
considerations.
I don't think there would be any particular issues with computing the
LFAs, since, as you say they would be done per topology. So I don't
think this document would need to say anything special. But the use
of the LFAs by multi-topology would probably need to have some
specific words about how they should be used, and as you say that
probably belongs in an MT specific document.
In other words, I agree!

        Mike



>>     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.
Changed.

>> 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
>> spec.
>
> Could you be more specific as to what you think may become a new security
> consideration?

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
    before")
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
    end-to-end)?
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
impact."
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."

Alia

_______________________________________________
rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

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