Subject: Comments on PPP Conversion draft

From: Chip Sharp <[email-masked]>
Date: Tue, 09 Dec 1997 11:52:54 -0500

General
---------
I support the designation of this as a BCP.

There is ambiguity in the definition of converter.  This is
understandable considering the proliferation of converter types in
the field.  There needs to be a distinction between conversion and
rate adaptation (e.g., V.120, V.110, etc.).  There seem to be many
that don't understand this distinction.  A converter must take some
active role in the handling of HDLC and/or PPP (even if it is
passive).

The draft is fairly vague about the failure modes of converters.
Some explicit examples would be appreciated.

Passive Converter
-----------------
To what level does a passive converter interact with PPP or HDLC?
For example, for asynch-synch conversion is it assumed that a passive
converter terminate HDLC on the asynch side and regenerate it on the
synch side?  

It would be clearer if an explicit example is given of a failure
mode.

In the fourth multiline paragraph, it isn't clear what model you are
using.  I assume this is a "low-speed" asynch to "high-speed" synch
converter.  An explicit example of options that fail would illustrate
the problem better.

Since the passive converter is not explicitly defined, it is unclear
what is being deprecated.

Active Converter
----------------
It seems that an active converter does more than intercept and
examine LCP messages.  It must actively participate in LCP messages,
modifying and/or adding options.  This is implied in the first
paragraph, but not clearly stated. In addition, it must also perform
operations on the actual data stream.

In the last paragraph of this section, it ight be useful to state
that ineffectual options should not be propogated.

Multilink
---------
I can't support this section as written.  There are many
asynch-to-synch PPP converters on the market that work fairly well.
They are much preferable to running V.120 over multiple links.
Therefore, the multilink section must be reworded to reflect this
fact.  If this is a BCP, then it should reflect the best current
practice of doing single link to  multilink conversion on an
asynch-to-synch converter.

If you wish, you could state that the use of single-link to
multi-link conversion is outside the scope of the document.

Chip
--------------------------------------------------
Chip Sharp			voice: +1 (919) 851-2085 
Cisco Systems		Consulting Eng -ISP/Telco			
--------------------------------------------------

---

From: "William Allen Simpson" <[email-masked]>
Date: Thu, 18 Dec 97 17:22:42 GMT

> From: Chip Sharp <[email-masked]>
Thank you.

> the field.

I thought the definition to be pretty specific:

   Some forms of bridging convert PPP encapsulated packets between dif-
   ferent framing formats.  It is the responsibility of the bridge to do
   all stuffing and framing conversions.

What is unclear?

> There needs to be a distinction between conversion and
> that don't understand this distinction.

Well, that's because they can sometimes do bridging, and sometimes
rate adaptation (adding an outer layer of framing to slow down the
effective link speed), trying to be all things to all people.  It's a
sick world out there....

Rate adaptation is entirely a waste of time in the packet context.

Does this BCP need to say that?  I wouldn't have thought it within the
scope of the title....

> A converter must take some
Yes, it takes the role of "Framing Conversion".

I suppose that some folks don't understand what "framing" is, but how
much of a tutorial are we expected to write in every document?

> Some explicit examples would be appreciated.
In the Introduction?  An example is already in the next section....

> Passive Converter

   A "passive" converter relies on outside PPP peers to conduct all LCP
   negotiation.  The converter inspects any LCP Configure-Acks passing
   through it, and dynamically updates its configuration accordingly.

PPP  -- passive LCP inspection.

What is unclear?

> converter terminate HDLC on the asynch side and regenerate it on the
Yes, of course.  There is a pretty big difference between the
transmission mechanisms; how could it be otherwise?

> converter.  An explicit example of options that fail would illustrate
Heck, the sync could be low-speed, too.  What does it matter?

   (such as Address-and-Control-Field-Compression, FCS-Alternatives, or
   another vendor specific option),

are already listed.

> what is being deprecated.
I thought the definition to be pretty specific:

   A "passive" converter relies on outside PPP peers to conduct all LCP
   negotiation.  The converter inspects any LCP Configure-Acks passing
   through it, and dynamically updates its configuration accordingly.

What is unclear?

> Active Converter
There is no such implication.  There is no modification or adding
options or passing LCP options across the bridge.  It _IS_ the LCP peer
-- ab initio.

   An "active" converter intercepts LCP configuration negotiation, while
   allowing other PPP traffic to pass unimpeded.  The converter becomes
   the PPP LCP peer on each interface, examining all LCP Link Configura-
   tion packets (Configure-Request, Configure-Ack, Configure-Nak, and
   Configure-Reject).

What part of "intercept" and "LCP peer" are not understood?

Could you suggest additional wording that would clear this up for you?

> that ineffectual options should not be propogated.
Why?  No options are propagated in any case.

In the previous paragraph it already says:

   Inappropriate or ineffectual options ....
   ...        Separate LCP negotiation on each interface prevents these
   options from propagating incorrect configuration information.

> asynch-to-synch PPP converters on the market that work fairly well.

Please name them.  Let's see an interoperability test of them.  I'll be
particularly interested in watching BACP operate on any two of them --
configured back to back....

> asynch-to-synch converter.
The best current practice is that it will not work correctly in all
cases, or even most cases, and therefore should not be used.

> multi-link conversion is outside the scope of the document.
I believe it to be in scope.  I believe it important, and others on this
list stated that it was important, to indicate that non-routing bridges
implementing PPP multi-link should not be used.

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

---

From: "Ian Puleston" <[email-masked]>
Date: Thu, 18 Dec 1997 14:35:17 -0800

-----Original Message-----
From: William Allen Simpson <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, December 18, 1997 11:01 AM
Subject: Re: Comments on PPP Conversion draft

>options or passing LCP options across the bridge.  It _IS_ the LCP peer

The converter must pass some LCP options across the bridge because these can
be negotiating capabilities of the end-points which it knows nothing about
(authentication protocol for instance).

This section seems to be saying that the converter must treat the two sides
as separate LCP sessions and carry out separate negotiations on both. That
would seem to be adding undue complexity for many cases. Take the case of a
convertor used to connect a PPP stack designed for ISDN to an ADSL link
running ATM:

The only conversion necessary would be to prevent the FCS Alternatives and
ACFC options propagating to the ATM side. It seems that this could be
achieved by simply returning a Configure Reject for these options in the
initial configure request, and then letting all further LCP negotiations
proceed end-to-end. The converter has no need for a full LCP negotiation FSM
(plus all the complexity of trying to tie the two sets of negotiations
together for options which need to go end-to-end).

The only obvious disadvantage I can see to this technique would be that the
PPP stack could receive two configure rejects, each rejecting a different
set of options (the 1st from the converter and the 2nd from the remote
peer). Would this cause a problem in exisiting PPP implementations ?

One other point. PPP converters could be categorized into two further types:
those which convert between two PPP links of different media, and those
which convert a PPP stack designed for one media type to run over a
different media (i.e. a stack which thinks it is running over media type X
may be running over type Y, via a converter, but with no media type X link
present). This type of converter could act differently to one where both
types of media are actually present - i.e. options specific to media type X
(such as ACCM for async links) can be rejected rather than accepted and used
on one side only. Maybe the RFC should mention this ?

---

From: [email-masked] (Jonathan Goodchild)
Date: Fri, 19 Dec 1997 12:25:16 +0000

It seems to me that there are several forms of active conversion, and it 
would be useful if the Framing Conversion draft addressed each 
explicitly, so that we know exactly what Bill Simpson intends to 
deprecate and why.

Anyway, here is my list of them, plus some comments.  

1) "Rejecting converter"

LCP negotiation takes place end-to-end, but the converter sends 
Configure Rejects for any options it doesn't like.
     
   Local Peer          Converter           Remote Peer
     
      <------------------ LCP ----------------->
                        |     |
            Cfg-Rej <---+     +---> CFG Rej
     
(This is the same as described by Ian Puleston, and I agree with what he 
said - as far as I can see, this solves the problems inherent in a passive 
converter.)

2) "Injecting Converter"
     
LCP Negotiation takes place end-to-end, but the converter injects 
additional options into Configure Request, and then sorts out any 
subsequent Rejects or Naks affecting these options.

(Personally, I doubt this can be made to work, and I'd be happy to see 
it deprecated.  But if someone out there has actually done it 
successfully.....)

3) "Negotiating converter"
     
Now there are several types of these; they are characterised by the fact 
the LCP is no longer end-to-end.  (Note I've ignored ECP and CCP, which 
could terminate at the converter or be end-to-end).
     
3a) Converter with End-to-End authentication
     
   Local Peer          Converter           Remote Peer
     
      <--------LCP------->     <-------LCP--------> 
      <------------------ Auth -------------------> 
      <------------------ NCP -------------------->

This seems to be what Bill Simpson means by an active converter (although he 
may mean #3b below).  In the multilink case, it would look like:

   Local Peer          Converter           Remote Peer
     
      <--------LCP------->     <-------LCP--------> 
      <------------------ Auth ------------------->
                               <-------MP--------->
                               <-------BACP------->
      <------------------ NCP -------------------->

As we discussed on the list back in July, this sort of converter has a 
real problem with authentication if the local peer is an authenticator.  
How does it authenticate the 2nd link?  For this reason alone, this sort 
of converter should be deprecated.  

However, I should like to take issue with Bill when he thinks that it 
won't interoperate.  I've actually implemented a converter exactly like 
this, and it works fine (authentication notwithstanding).  I'm sure 
several others have similar implementations.

3b) "Authenticating converter"
     
   Local Peer          Converter           Remote Peer
     
      <--------LCP------->     <-------LCP-------->
                               <-------Auth------->
                               <-------MP--------->
                               <-------BACP------->
      <------------------ NCP -------------------->
     
(Authentication could also take place between the converter and the 
local peer as well).

This sort of converter seems to solve the problem of #3a, but isn't a 
router (as I understand it anyway).  Perhaps Bill would care to explain 
exactly why he thinks it won't work and why it should be deprecated in 
the multilink case.  

4) Router
     
Just for reference, here is my understanding of what a router is.
     
   Peer                  Router           Peer
     
      <--------LCP------->     <-------LCP--------> 
      <--------Auth------>     <-------Auth------->
                               <-------MP--------->
                               <-------BACP------->
      <--------NCP------->     <------ NCP-------->

5) Passive Converter

If other people are really not sure what it meant by this, perhaps a 
good definition would be that a passive converter alter the framing, 
while leaving the PPP Encapsulation (as defined in RFC 1661 section 2) 
unchanged.  

Or can a passive converter change the padding as well?

---
Jonathan Goodchild

P.S. This may be my last contribution to the list for a while (I can 
almost hear Bill cheering!) - it seems quite likely that I am about to 
make an involuntary career move.  (If anyone is interested, I'll send 
them details privately).

---

From: "William Allen Simpson" <[email-masked]>
Date: Sun, 21 Dec 97 14:26:02 GMT

> From: [email-masked] (Jonathan Goodchild)
Only one form of "active" converter is discussed in the current draft,
and none of those on your list are recommended.

The text is:
   An "active" converter intercepts LCP configuration negotiation, while
   allowing other PPP traffic to pass unimpeded.

A diagram of the form that you used would be:

   Peer                 Converter                 Peer

      <--------LCP------->    <--------LCP-------->
      <------------------ Auth ------------------->
      <------------------  ML  ------------------->
      <------------------ BACP ------------------->
      <------------------ NCP -------------------->

>       <------------------ NCP -------------------->
Incorrect!  How does the converter "know" to intercept multi-link and
BACP (and MPP+ et alia)?  Omniscience?  Prescience?

> several others have similar implementations.
Sorry, I don't believe you.

Please demonstrate with CHAP and EAP authentication negotiation.

Please demonstrate this by first linking the peers directly, and then
inserting a pair of converters (as in your previous example) back to
back, without any additional configuration of either peer (as you
demanded in your message some months ago).

> (Authentication could also take place between the converter and the
Incorrect!  Configuration nightmare!  How does this box without an IP
address have RADIUS access?

Note that multi-link will still not work correctly.

>       <--------NCP------->     <------ NCP-------->
Correct.

Thank you for the contribution.  I will add similar diagrams.

Apparently, some folks are having trouble visualizing the textual
descriptions.  (This did not appear to be a problem in the in-person
verbal presentation, so there is clearly a dichotomy in expectation for
"hearing" text words and "reading" text words.  Perhaps the diagrams
will help.)

[email-masked]

---

From: "William Allen Simpson" <[email-masked]>
Date: Sun, 21 Dec 97 14:16:03 GMT

> From: "Ian Puleston" <[email-masked]>
Sorry, won't work.  The bridge has to do the authentication negotiation.
If the bridge does not understand the option, then it will not work.

> as separate LCP sessions and carry out separate negotiations on both.

Correct!

> That
Certainly a very complex case; but if you want the complexity of ATM,
then you have to live with complexity.

> ACFC options propagating to the ATM side.

How do you know that?  Prescience?

What about new options?
What about vendor specific options?
What about multi-link options?

> It seems that this could be
Sorry, won't work.

> peer). Would this cause a problem in exisiting PPP implementations ?
Damn straight!

> present).

Huh?

> This type of converter could act differently to one where both
I do not understand your scenario.

[email-masked]

---

From: [email-masked] (Jonathan Goodchild)
Date: Mon, 22 Dec 1997 10:24:24 +0000

>> In the multilink case, it would look like:
>>
>>       <------------------ NCP --------------------> >

Well, since single-link to multilink conversion is the raison d'etre 
for the converter, the knowledge is hard-coded.
     
> Sorry, I don't believe you.

What, that others have similar implementations?  Or that it works if 
there is no authentication?

> demanded in your message some months ago).

I can't do that because, as I said myself in my message, it doesn't 
work when the local peer is the authenticator (in the case of 
converters at both end, then both peers are local peers to their 
respective converters).  

I don't think there is any disagreement here - I said myself that this 
sort of converter should be deprecated.  I just thought it worth 
discussing because there are several converters like this in existence.

>> (Authentication could also take place between the converter and 
>> the local peer as well).
>>
> Incorrect!  

Again, what do you mean precisely?  Are you referring to my sentence in 
parentheses?  I agree that #3b is an incorrect interpretation of what 
you meant by an active converter.

> Configuration nightmare!  

Quite possibly.  But if, for example, the converter is a terminal 
adaptor, then it has another means with which to communicate to the 
local peer (i.e. AT commands).

> How does this box without an IP address have RADIUS access?

It doesn't, of course.  I hadn't realised that RADIUS was mandatory.  
Clearly, if you want RADIUS, then you have to have a router.
     
> Note that multi-link will still not work correctly.

Perhaps others on the list would care to refute this statement.  Obviously 
I'm not going to succeed in convincing you that it does work.
     
> Thank you for the contribution.  

You're welcome.

> I will add similar diagrams.

That would certainly be very useful.

---
Jonathan Goodchild

---

From: "Ian Puleston" <[email-masked]>
Date: Mon, 22 Dec 1997 10:17:08 -0800

>If the bridge does not understand the option, then it will not work.

So how does the bridge know which authentication protocols are supported by
the end-point? Omniscience?  Prescience?

>What about multi-link options?

OK, it prevents the FCS Alternatives and ACFC options propagating to the ATM
side, and rejects any options which it does not recognize from either side.
I assumed the latter would be taken as read.

>> together for options which need to go end-to-end).

Would you deign to enlighten us as to why ?

>I do not understand your scenario.

OK here's a real example:

A computer contains a PPP stack designed to run over an internal ISDN card
and written to RFC-1618 (PPP over ISDN). It is desired to connect some of
these computers to an ATM network, but the computer OS manufacturer has no
plans to upgrade its PPP stack to support the PPP over ATM RFC. So, the PPP
card is replaced with an ATM card, and the ATM card driver does the
necessary conversion. The driver is therefore a converter between RFC-1618
and the PPP over ATM RFC, but in fact there is no physical ISDN line
involved.

---

From: "William Allen Simpson" <[email-masked]>
Date: Tue, 23 Dec 97 03:12:25 GMT

> converters at both end, then both peers are local peers to their
Actually, you said "it works fine (authentication notwithstanding)."

It was not obvious that meant it did not work with authentication.

> discussing because there are several converters like this in existence.
This is the IETF.  Once upon a time, we used to pride ourselves on not
being like ISO.  We made choices.  We did not standardize things just
because they are "in existence".  Especially when they are known to have
severe failure modes.  Most especially when the failure mode involves
security!

Since you and I and the folks at the IETF DC meeting are in agreement
that this sort of thing should be deprecated, then let's get on with
it....

[email-masked]

---

From: "William Allen Simpson" <[email-masked]>
Date: Tue, 23 Dec 97 02:11:11 GMT

> the end-point? Omniscience?  Prescience?
There is only one LCP option for authentication.  The bridge either
understands it (passes), or does not (fails).  The A-P option does not
affect framing.

The authentication protocols themselves are not part of LCP (by design).
They pass right thru the framing converter, whether the framing
converter is active or passive.

The end user is never confused by a bridge that appears to successfully
negotiate, but does not actually pass network traffic (the stated
problem that we are solving).

> Would you deign to enlighten us as to why ?
Please re-read the PPP archives of several months ago on this topic.  As
you do the "thought experiments" to answer the questions explicitly
raised, it seems rather obvious.

As much as PPP is personally important to me, I get tired of typing the
same thing over and over, year after year.

Alternatively, I have been known to provide face-to-face tutorials, when
I'm paid enough.

> and the PPP over ATM RFC, but in fact there is no physical ISDN line
No wonder I didn't understand that.  Speaking as the implementor of the
first PPP on PRI using the Rockwell board in early '92, I just didn't
envision someone doing _anything_ this way ... the performance must be
abysmal.  This gives rise to a series of questions:

Who is shipping this "real example"?

Are you sure the ISDN bit-stuffed or (optional) octet-stuffed framing is
done in software in the PPP stack?

At a higher level than the ISDN driver that is being replaced?

Isn't framing done in the ISDN card itself?

Isn't framing done in the ATM card itself?

Does the ATM driver convert the framing by emulating bit-destuffing or
octet-destuffing, and then re-stuffing?

Please remember that we are talking about framing.  Otherwise, it might
be some other kind of converter, but I doubt that is in scope for the
Framing Conversion document.

[email-masked]

---

From: [email-masked] (Jonathan Goodchild)
Date: Tue, 23 Dec 1997 10:27:24 +0000

>"William Allen Simpson" <[email-masked]>
>> So how does the bridge know which authentication protocols are supported 
>> by the end-point? Omniscience?  Prescience?
>>
     
Can we look at this in a bit more detail.  Going back to the diagram for 
an active converter:
     
  Peer                 Converter                 Peer

For authentication to take place end-to-end, both peers need to agree on 
an authentication protocol, plus any associated options.  So the 
converter has to relay the contents of the authentication option from one 
side to the other.   The converter therefore can't implement LCP exactly 
according to the FSA in RFC 1661, but has to implement extra events (and 
possibly states).  
     
For example, the Open event in state 2 normally results in irc,scr/6.  
But the converter can't send out a Configure Request until it has 
received a Configure Request on the other interface, otherwise it doesn't 
know what authentication option to include (the same also goes for other 
options like MRU).  
     
In addition, the responses to received configure requests are dependent 
on what is received on the opposite interface.
     
So this is a lot more complicated than it may appear at first sight.  Ok, 
it can be made to work (I know, because I've done it).
     
But it may be worth including some text in the draft RFC to explain the 
difficulties.

>> >Sorry, won't work.
     
(This was about what I described as a "Rejecting Converter" in a 
previous message, i.e. a converter that sends Configure Rejects in 
response to options in Configure Requests which it doesn't like, but 
otherwise passes everything through.)

>>
>> Would you deign to enlighten us as to why? 
>>
> Please re-read the PPP archives of several months ago on this topic.  
> As you do the "thought experiments" to answer the questions explicitly 
     
Well, I've read the archives and I can't find anything which provides an 
explanation.
     
> Alternatively, I have been known to provide face-to-face tutorials, 
> when I'm paid enough.
     
Ah, so that's why it's so difficult to get anything other than bald 
statements out of you.

---
Jonathan Goodchild

---

From: "William Allen Simpson" <[email-masked]>
Date: Tue, 23 Dec 97 14:26:50 GMT

> side to the other.

Sure, that's a given.  I disagree about "any associated options".  The
standard PPP options, such as A-P, are designed to be self-contained and
independent.

There are many other options that could be relayed as well.
Compression and encryption, for example.

But if you don't relay them, the link will still come up.  That's how
PPP is supposed to work!

> The converter therefore can't implement LCP exactly
I don't see any additional states.

> know what authentication option to include (the same also goes for other
I disagree.  Of course you send the C-Req immediately!  And when you get
another C-Req on the other interface that has another option specially
configured for passing through, like authentication or compression or
encryption, you just send another C-Req.  Easy!  The FSA requires that a
C-Req can be sent and received at any time.

Of course, there are broken stacks (mostly from MicroSoft) that won't
work, but anyone who depends on a broken stack has no business being in
business....  Vote with your wallet.

As to MRU, you usually will not want to relay that, as you might not be
able to dynamically adjust your internal buffers.  Implementation
specific detail.

> it can be made to work (I know, because I've done it).
Sure, but that's true with a NAS using RADIUS.  This is the usual way of
implementing PPP, isn't it?  Not terribly complicated to an experienced
implementor....

> But it may be worth including some text in the draft RFC to explain the
I'll do my best.

> Ah, so that's why it's so difficult to get anything other than bald
It might have something to do with the fact that I get circa a thousand
messages a day, and try to keep my email time to 3-5 hours per day....
And nobody is paying me for email time.  FYI, this reply took over 20
minutes to write.

Short, specific, concise messages are all I send.  Thinking thru the
detail, you have to do for yourself.  I expect that of anyone.  This is
an implementors forum, not a tutorial forum.

I should not have to re-explain general concepts like "Most Significant
Bit" that any engineer with an iota of experience already understands,
and I have already written in multiple documents.  When I write
something once, I'm loath to write it again (unless I cannot remember
which of the archives of the past 20 years the previous message is in).

And you may have noticed, I really _hate_ nebulous, passing thought,
non-specific, maybe we could do this, speculation.  If you want WG
attention about a problem, you need to be up front about which actual
product has the problem.

[email-masked]

---

From: "Ian Puleston" <[email-masked]>
Date: Tue, 23 Dec 1997 11:30:19 -0800

-----Original Message-----
From: William Allen Simpson <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, December 22, 1997 7:39 PM
Subject: Re: Comments on PPP Conversion draft

>> So how does the bridge know which authentication protocols are supported
by
>understands it (passes), or does not (fails).  The A-P option does not

Certainly there is only one LCP option, but it can take more then one value.
Some PPP implementations (maybe unwisely, but they do it) allow the peer to
negotiate an authentication protocol which both ends support. Peer A says
use CHAP, peer B returns a Nak specifying I don't support CHAP but I could
use PAP, and peer A says OK use PAP. That is what the bridge cannot handle
without knowledge of the capabilities of the end-points, or passing the LCP
options across.

>converter is active or passive.

Understood and agreed.

>Who is shipping this "real example"?

I meant "real" as in a real problem waiting to be solved, particularly with
ADSL coming along. However there was an announcement recently from ATML,
quote from their web site: "ATML's implementation of the PPP driver uses
Microsoft's standard PPP stack and binds it to the ATM NIC inside the PC. "

>Framing Conversion document.

Most of the framing is done in the ISDN card, the FF,03 HDLC header being
inserted by the PPP stack. However the negotiations of what framing to use
(e.g. address/control field compression, alternate FCS if supported) are
done by the PPP stack. Don't forget that the PPP over ATM RFC states that we
MUST NOT negotiate framing options which don't apply to ATM. The converter
is not just a framing converter, it is also a converter of options applying
to framing.