Re[4]: PPP over IPSec (without L2TP)?

[Jim Tiller <[e-mail]>]

OK, but I keep choking on one aspect.

If PPP is encapsulated into L2TP, which basically assumes the
form of an IP packet (right?) Doesn't the same issues of
reordering exist? Eliminate IPSec for a second. I'm
obviously not an L2TP dude, but I'm aware of in-band
controls within L2TP that provide the options to the
passenger protocol(s).
I guess my misunderstanding revolves
around that if a packet is ultimately forwarded through an
IP network, the odds of packets arriving at the destination
in the wrong order are high. At that point don't the
packets get reordered by the IP stack of the receiving system
and then passed up the stack? At that point aren't the PPP
LCPs and NCPs reordered inherently prior to de-encapsulation?

Please be patient with me, I know I'm missing a critical
step and completely over simplifying the process.
I just don't see the need for L2TP
over IPSec, it's not sticking.

Thankx for your time!

-jim

Thursday, October 14, 1999, 1:19:37 PM, you wrote:



>> From: Jim Tiller [mailto:[e-mail]]
>> Sent: Thursday, October 14, 1999 12:54 PM
>> To: Shriver, John
>> Cc: 'Ari Huttunen'; [e-mail]; [e-mail]
>> Subject: Re[2]: PPP over IPSec (without L2TP)?
>> 
>> Excuse my ignorance, but doesn't IPSec and IP handle this in
>> layer three and four? I'm personally torn on the use of L2TP
>> over IPSec, I see certain implementations that can benefit,
>> but the reasons MS gives do not impress me.
>> Any comments are welcome.
>> 

Shriver> Well, for the DATA path, PPP itself has no concerns about packet reordering.
Shriver> IP over PPP could care less.

Shriver> But, some of the protocols over PPP care very much about reordering.  IEEE
Shriver> 802.1D bridging assumes essentially no possibility of reordering, so BCP
Shriver> over PPP has to assume that what is under PPP will not reorder.

Shriver> But, the big problem is the entire PPP negotiation state machine.  (The
Shriver> CONTROL path.)  It is absolutely designed on the assumption that the data
Shriver> link underneath will never reorder packets.  Suppose a NCP Config-Ack was
Shriver> sent by an IPCP Config-Request.  If they were swapped in transit, the IPCP
Shriver> packet would be received before NCP was up.

Shriver> Also, the Van Jacobsen TCP header compression really benefits greatly from
Shriver> being informed of packet loss at the receiver.  L2TP can provide some hint
Shriver> of that.