Subject: Re: comments on IPFRR drafts

From: "Alia Atlas" <[email-masked]>
Date: Fri, 8 Dec 2006 17:22:57 -0800

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-masked]> 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.

> >>     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-masked]
https://www1.ietf.org/mailman/listinfo/rtgwg

---

From: mike shand <[email-masked]>
Date: Mon, 11 Dec 2006 10:19:37 +0000

>for alternates would be per topology, but there might be some special

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

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 11 Dec 2006 10:44:27 +0000

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

Maybe we should say more than "out of scope" perhaps something along
the lines of Mike's comments. Whilst I agree that the bulk of the text
should be in a MT doc, I would not like to leave people with the
impression that LFA does not work, or breaks under LFA.

- Stewart