Subject: Re: draft-ietf-pppext-sonet-ds-00.txt

From: "William Allen Simpson" <[email-masked]>
Date: Sun, 23 Nov 97 21:02:25 GMT

> From: Stuart Venters <[email-masked]>
> First the "Applicability" section. IMHO, (and given the benefit of 20-20
> hind site,) I think you are solving the wrong problem.  While there may
> be a need for an intra-campus Sonet spec, there is definitely a need for
> a full wide area spec which is fully Sonet compatible.  Wouldn't overall
> interoperability be better served if we gave up interoperability with the
> original 1619 and cut over to some other scheme which is fully compatible
> with the actual wide area Sonet installed base?
>
Where is this not fully compatible?  There have been no verified
examples given where it is not....  Please be specific.

And if you knew of a specific problem, why didn't you raise this on the
PPPSDH list while we were reviewing the document section by section for
compatibility issues?

> Second, the "Prophylactic Octet Stuffing" section.  I still think
> some sort of scrambler is the best final solution, but if you insist that
> interoperability with the original 1619 is an overiding concern, then i
> see two major holes in this section.
>
> One is that the scheme is too predictable.  If an
> attacker can guess how the countermeasures will react then he has a high
> probability of defeating them.  Perhaps the stuffing threshold should be
> random?
>
What possible attack is there?  Please be specific.

And what would be the effect of such an attack?  Loss of the data of the
attacker?  Loss of someone else's data?  How often?  For how long?

> The other is the limited choice of expected attack patterns.  Consider an
> attack where the byte pattern on the fiber after the sonet scrambler is
> mostly zeros with a one sprinkled in every 10 to 20 bits.  The pattern
> detector would see nothing but the physical fiber interfaces would have a
> problem due to the duty cycle of the signal.
>
Duty cycle is a good point.  Which fiber interfaces have this problem?
(A self-synchronous scrambler does not solve this problem.)

Other possibilities include long 10101010 or 01010101 sequences.  There
are lots of possible clock recovery problems.  A self-synchronous
scrambler pattern does not solve any of them....

As I've mentioned a few times, it all comes down to the stability of the
receive clocking design.  A bad design will have problems.  A simple and
effective design, say an external clock running at 16 times the data
rate, should have no problems at all....

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32

---

From: Stuart Venters <[email-masked]>
Date: Mon, 24 Nov 97 8:45:18 CST

> Where is this not fully compatible?  

Bill,

Please clarify the ground rules for me:

     The Applicability section of rfc-1619 has consistantly said that the
     PPP over Sonet spec IS NOT ACCEPTABLE for the public Sonet
     infrastructure.

     You (in your above response) appear to be saying that it
     IS ACCEPTABLE for the public Sonet infrastructure.

     Which way do you think it should be?

Sincerely,
Stuart Venters
(The views expressed are not necessarily those of my employer.)

---

From: Dennis Ferguson <[email-masked]>
Date: Sat, 29 Nov 1997 18:18:32 -0800

> scrambler pattern does not solve any of them....

A scrambler actually does solve this problem about as well as it needs to
be solved by ensuring that patterns which cause duty cycle problems will be
as infrequent for PPP over SONET payloads, independent of the data that is
sent inside the packets, as they are for any other SONET payload.  There is
no purpose served by doing better than this, the aim is only to avoid doing
worse.

Dennis Ferguson