Subject: Re: comments on IPFRR drafts

From: Alex Zinin <[email-masked]>
Date: Sun, 4 Jun 2006 22:58:52 -0700

Pekka,

Thanks a lot for reviewing the documents!

> I draft-ietf-ipfrr-spec-framework-05.txt, but I don't have anything to
> comment except that maybe [MICROLOOP] reference should be 
> draft-ietf-rtgwg-microloop-analysis-01.txt instead of 
> draft-bryant-shand-lf-conv-frmwk-02.txt.

> I also read draft-ietf-ipfrr-spec-base-05.  It looked rather good, but there
> seemed to be some omissions that should probably be addressed.

> substantial
> -----------

==>> this document only mentions IS-IS and OSPF(v2).  Is it directly
> applicable without any mods to OSPFv3 as well?  If so, refer to it as well;
> if not, describe the differences.  I'm assuming IPv6 for IS-IS should work
> without any issues as well.

Yes, neither OSPFv3 nor IS-IS for v6 should require any special provisions,
as next-hop calculations are the same.

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

> I'm assuming the
> regular OSPF/IS-IS TE extensions work without problems?

Yes, they are not affected by the FRR.

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

> Btw, is it feasible to use RFC4205 or RFC4203 on non-GPMLS, non-IGP-TE networks
> in any case?  Are there alternatives?

There's nothing that stipulates that GMPLS extensions can't be used in a
pure-IP network. It's a question of enabling the announcement in the
domain.

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

Editorial below are fine.

--
Alex

> editorial
> ---------

>        P_i.alt_next_hops = {}
>        P_i.alt_type = NONE P_i.alt_link-protect = FALSE
>        P_i.alt_node-protect = FALSE

==>> the middle line should probably be split to two lines..

>     It is possible to provide ASBR protection if BGP selected selected a
>     set of IGP next-hops and allowed the IGP to determine the primary and

==>> remove one "selected".

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 5 Jun 2006 09:32:28 +0300 (EEST)

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

> We can say "may be obtained".

That's be good.

> 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
    before")

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

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

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