[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Windows 2000 and Cicsco router interoperability
Mark,
>2 bytes and you get multiprotocol capability. Heck, it would not be too
>difficult to even reduce this to 0 bytes if one is *that* concerned and
>does not mind limiting oneself to a single NCP within PPP.
If one were using these tunnels for carrying protocols other than IP,
I would agree completely. But, tunneling IP in this fashion is a
layering anomaly and I always object to such anomalies.
>
> > essential for the function in question. Still, from a single, dialup
> > host, it's not clear under what circumstances the multi-packet muxing
> > will be invoked.
>
>The driving force for ppp mux as I remember is for voice packets at
>aggregation points in a wireless network. There could be others, but the
>point I was really making is that there are all sorts of things that the
>pppext WG has done for point to point remote access connections. What
>makes a secure tunnelled point to point connection so special? I see a
>VPN connection stepping in to replace what was traditionally a dialup or
>leased line. Utilizing the facilities that are in place and expanding
>upon them makes a great deal practical sense.
I do see a basis for disagreement here as well. IPsec is a mechanism
that does more that create a crypto-protected path. Access control
is integral to IPsec because of the need to bind crypto-authenticated
identity and a set of policy-based security parameters to the path,
so as to provide better security. The problems we're seeing here is
that there are multiple points at which to effect the access control,
based on the context in which IPsec is used. However, most of these
have the property that they were not articulated in IETF standards at
the time IPsec was developed, certainly not at the time we initiated
the IPsec work, and not even at the time the IPsec RFCs were issued.
Moerover, stand alone, native IPsec devices are common and represent
the only (current?) means to achieve high speed IPsec service. When
such devices are used, one cannot achieve the same level of access
control via external devices (e.g., firewalls), so it seems to make
sense to retain these features as part of the IPsec spec. As noted
before, if a single device implements multiple functions, e.g., IPsec
and a firewall) then it can be IPsec-compliant if the black box
functioning of the device is consistent with (or is a superset of)
what is reuqired soley for an IPsec module.
Steve
References: