Subject: Re: [Isis-wg] Question on DCC Architecture

From: Jonathan Sadler <[email-masked]>
Date: Mon, 18 Dec 2000 16:01:14 -0600

However, use of PPP on the Section DCC may cause an interoperability
issue if you have a regenerator in line, and it only supports
CLNP/LAPD.  For that reason, GRE encapsulation (ala the Cisco 15303), or
IP over LAPD (ala RFC 1663?) may be a better approach, until a standards
body puts a stake in the sand.

Another issue not covered is the operational use of IS-IS on this
channel.  As IS-IS is used by SONET terminal/regenerator gear, what is
going to happen to all the CPU and memory constrained ADMs out there
when they start receiving the LSPs with all of the TE and GMPLS TLVs? 
Many are limited to less than 50 nodes and less than 100 links in an
Area -- and the Node/Link TLVs are certainly smaller than the TE/GMPLS
TLVs.

Jonathan Sadler

[email-masked] wrote:
> 
> Alex Zinin writes:
> >  A number of companies working in the SONET area already use or are
> >  planning to use DCC for IP control plane [I put MPLS list back ;),
> >  since this question is related to GMPLS and OTN-related work].
> >
> >  There are two types of IP encapsulation on DCC that I know of:
> >  LAP-D and PPP/HDLC. We use the second one in our SONET products.
> >
> >  I think writing up an IETF document describing this would make sense.
> 
> Describing which part?  I think there are at least three separate
> issues here.  One is the control plane issue (specifying the use of IP
> over DCC for carrying control messages), another is the encapsulation
> (for which RFCs 1332, 1661, and 1662 should do fine), and a third is
> having ITU-T specify that PPP is a "legal" option for DCC.
> 
> For the first two issues, I think those are already handled.  It's
> just that third one that might be an issue for some users, and I don't
> think that can be done within an IETF working group.
> 
> If you're suggesting a BCP saying that IP/PPP/HDLC/DCC is a good
> thing, I suppose that's possible, but I don't see what it
> accomplishes.
> 
> --
> James Carlson, Internet Engineering       <[email-masked]>
> SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
> Second Edition now available - http://people.ne.mediaone.net/carlson/ppp

---

From: Mike Truskowski <[email-masked]>
Date: Tue, 19 Dec 2000 7:59:16 PST

The issue is simply stated... while you look at ISIS to
enhance it for "IP".  Don't break it for "CLNS" because 
there are 10's of thousands of sonet/sdh NE's relying on
ISIS today.

Certainly, we in the NSIF can move forward creating an IP
stack... but the rings which are already using clns on
the DCC will be there for awhile longer.

I would prefer running a native protocol end2end while others
would rather see clns on the dcc and ip2clns mediation on
the DCN.
There are no simple answers here. 

Mike

> This is something that a body equivalent to Nanog in SONET world should 
> probably be concerned with. ISIS working group has as primary topic the 
> standardization of bits on the wires between boxes to make sure that 
> different vendors interoperate. Although things like application
> guidelines and protocol analysis is common, it would be vain trying to 
> publish RFCs with implementation guidelines since technology is still
> galloping forward @ a speed that makes such publications often obsolete
> within months. As to deployment issues with older gear that you outline,
> IETF has been pretty much shaped by the Darvinian ISP approach "get them to 
> upgrade your software, get them to upgrade your hardware, if they can't,
> throw the gear away and pick up a better vendor". As an alternate solution,
> you may just choose not to deploy all that optional new stuff ..
> 
> 	--- tony
> 
> _______________________________________________
> Isis-wg mailing list  -  [email-masked]
> http://external.juniper.net/mailman/listinfo/isis-wg
>

---

From: John Harper <[email-masked]>
Date: Tue, 19 Dec 2000 21:09:39 +0000

Not true - there are BIG security advantages to not having is-is over ip. 
It rules
out a huge class of spoofing attacks to which OSPF is vulnerable. Further,
there are no evident advantages to having is-is over ip, at least not that I
have ever heard of.

         John

At 08:06 19/12/2000 -0800, Randy Bush wrote:
>there are small security advantages to NOT having is-is over ip
>
>randy

---

From: Dave Katz <[email-masked]>
Date: Tue, 19 Dec 2000 13:54:44 -0800 (PST)

There was the ATM-VCMUX-encaps-to-avoid-two-cell-TCP-ACKs argument,
but Henk's NLPID scheme (a truly wonderful reverse-ISO hack) is a hell
of a lot simpler.

---

From: Jeff Learman <[email-masked]>
Date: Tue, 19 Dec 2000 17:04:42 -0500

I don't think this thread (IP on SONET DCC) has anything to do with
IS-IS over IP.  Please pick a new topic if you have something
to say about that.

Thanks,
Jeff

At 10:20 PM 12/19/2000 +0100, Tony Przygienda wrote:
>> out a huge class of spoofing attacks to which OSPF is vulnerable. 
>
>last I checked nobody saw them so the whole thing is more a mental
>construct than reality. And even if, running proper security in your 
>routing protocol is a pretty good answer to that ...
>
>> Further,
>there are some, they are just not that important at the moment and that's
>why the work is dormant. One day we may run out of patience defining IS-IS
>encaps for every new link-layer technology that comes our way or really 
>want to solve the MTU problem or maybe simply run out of smallest MTU times
>255 LSPs bytes space in the protocol and then it may become a very handy tool
>
>	thanks 
>
>	-- tony
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Dec 2000 08:06:28 -0800

randy

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 19 Dec 2000 00:13:03 +0100 (MET)

--- tony

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Dec 2000 17:28:09 -0800

> Not true - there are BIG security advantages to not having is-is over ip. 

not being in sales or at a vendor, i am used to making more moderate claims
:-)

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 19 Dec 2000 22:20:22 +0100 (MET)

thanks 

	-- tony

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 19 Dec 2000 17:05:12 -0500

>to not having is-is over ip. 
        
        Randy was right, IMHO, the advantages are modest.

>It rules out a huge class of spoofing attacks to which OSPF 
>is vulnerable. 

        OSPF is not vulnerable at all to spoofing attacks
if configured properly (e.g. MD5 enabled, reasonable keys chosen).

>Further,
>there are no evident advantages to having is-is over ip, 

        Agree.

Ran
[email-masked]

---

From: Randy Bush <[email-masked]>
Date: Tue, 19 Dec 2000 18:02:26 -0800

>> It rules out a huge class of spoofing attacks to which OSPF is
>> vulnerable.
> last I checked nobody saw them

i assure you that the ops community, at least the wiser part of it, sees
them.

> And even if, running proper security in your routing protocol is a pretty
> good answer to that ...

except the beast does not exist.  md5 sigs are not considered strong.

randy

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 20 Dec 2000 03:46:31 +0100 (MET)

> i assure you that the ops community, at least the wiser part of it, sees

I didn't argue that they don't _exist_, I argued that I didn't hear of many
incidents where ISP OSPF backbones were target of such attacks (contrary to
some fancy BGP TCP attacks ;-) And if such attacks are being performed and 
I'm unaware of those, doing things like dropping OSPF packets with TTL>1
(with necessary exceptions) is a fairly trivial fix on the fast-path 
for many vendors. 

> except the beast does not exist.  md5 sigs are not considered strong.

about 1 1/2 years ago there was some wind that some guy came close to crack
MD5 with serious computing power but didn't happen as far I heard. 

I get the impression that we're arguing here for the sake of the argument now
and not the technical content anymore, so that's my last e-mail on this
thread.

BTW, Randy and others, 
pls subscribe to isis-wg list if you keep posting to it, otherwise
it's quite a pain to let e-mails of non-subscribers in since we're running it
moderated (which is a very good solution, thanks to Juniper hosting it ;-)

	-- tony