Re: Future of the PPP WG

--===============8742350274276829483==
Content-Type: multipart/alternative; boundary=20cf307d00d0877f3b04acca987c

--20cf307d00d0877f3b04acca987c
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Sep 10, 2011 at 11:37 AM, Vernon Schryver <[email protected]> wrote:

> > From: Thomas Narten <[email protected]>
>
> >            (By that, are there still folk doing PPP implementations
> > that would read such documents?)
> >
> > This WG's current charter seems to be very realistic and pragmatic
> > given the state of both PPP and the WG. We should not be updating the
> > charter to add items that will in practice never get done, no matter
> > how much we might like to see such work getting done (in an ideal
> > world).
>
> A more accurate way to say that is that this WG should not be turned
> into a vanity press for old folks trying to prove we're not irrelevant.
>
> If there is real and substantial work to be done, then it should be
> proposed before changing the charter in sufficient detail to convince
> honest and well informed third parties that and how the charter should
> be changed.
>
> Observations that the security of PPP protocols might be improved
> would be valid but entirely insufficient.  Significant needs and
> potential fixes must be proposed before starting yet another
> multi-year PPP project that would not finish before IPv4 address
> exhaustion finally makes IPv6 real.
>
> Actually, we are trying to get things done in real world to smooth the path
to IPv6, which seems
to be welcome by some ISPs, since, there is a gap in the case of PPP for
IPv6.
I know it may have been discussed, and a suggestion was given, but some ISPs
whose access networks are 90% based on PPP, and who are planning to deploy
IPv6 for their comercial services, are not convinced.

There're still works need to be done.


Cheers,
Jacni


>  ...
>
> Personally I think PPP insecurity was never a very pressing problem,
> because link layer security never mattered as much as security at
> higher layers.
>
> Besides, other link layer protocols such as 802.11 that are more
> popular (measured by nodes using them) and less secure (as commonly
> deployed) make the insecurity of PPP links moot.  What bad guy would
> bother attacking a PPP/DSL link when a radio can get bits on and
> off the same PPP link easier and with fewer traces?
>
> Link layer encryption, authentication, and authorization don't
> matter a lot if you have end-to-end confidentiality, authentication,
> authorization, non-repudiation, etc.  On the other hand, if you
> haven't secured things end-to-end, then link layer security is
> snake oil.
>
> If you've the least connection to today's operational security
> community, you know that the worst that could happen with a link layer
> attack is trivial compared what happens now in higher layers.  Even
> if this WG could fix PPP security this decade, wouldn't the effort
> of the rest of the IETF in reviewing, advancing, and shuffling our
> documents be better spent in the higher layers?  Recall BPG security,
> what DigiNotar and Comodo prove about PKI (that we all knew many years
> ago), old style insecure DNS, DNSSEC vulnerabilities analogous to the
> PKI problems, the RIR issues, and so forth and so on and on.
>
>
> It would be nice to fix nasty messes such as PPPoE, but that ship
> has also sailed.
>
>
> Vernon Schryver    [email protected]
> _______________________________________________
> Pppext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pppext
>

--20cf307d00d0877f3b04acca987c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<font face=3D"verdana,sans-serif"><br></font><br><div class=3D"gmail_quote"=
>On Sat, Sep 10, 2011 at 11:37 AM, Vernon Schryver <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:[email protected]">[email protected]</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex;">
&gt; From: Thomas Narten &lt;<a href=3D"mailto:[email protected]">narten@us=
.ibm.com</a>&gt;<br>
<div class=3D"im"><br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0(By that, are there still folk doing PPP implem=
entations<br>
&gt; that would read such documents?)<br>
&gt;<br>
&gt; This WG&#39;s current charter seems to be very realistic and pragmatic=
<br>
&gt; given the state of both PPP and the WG. We should not be updating the<=
br>
&gt; charter to add items that will in practice never get done, no matter<b=
r>
&gt; how much we might like to see such work getting done (in an ideal<br>
&gt; world).<br>
<br>
</div>A more accurate way to say that is that this WG should not be turned<=
br>
into a vanity press for old folks trying to prove we&#39;re not irrelevant.=
<br>
<br>
If there is real and substantial work to be done, then it should be<br>
proposed before changing the charter in sufficient detail to convince<br>
honest and well informed third parties that and how the charter should<br>
be changed.<br>
<br>
Observations that the security of PPP protocols might be improved<br>
would be valid but entirely insufficient. =A0Significant needs and<br>
potential fixes must be proposed before starting yet another<br>
multi-year PPP project that would not finish before IPv4 address<br>
exhaustion finally makes IPv6 real.<br>
<br></blockquote><div>Actually, we are trying to get things done in real wo=
rld to smooth the path to IPv6, which seems<br>to be welcome by some ISPs, =
since, there is a gap in the case of PPP for IPv6.<br>I know it may have be=
en discussed, and a suggestion was given, but some ISPs whose access networ=
ks are 90% based on PPP, and who are planning to deploy IPv6 for their come=
rcial services, are not convinced.<br>
<br>There&#39;re still works need to be done.<br><br><br>Cheers,<br>Jacni<b=
r>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0=
pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
=A0...<br>
<br>
Personally I think PPP insecurity was never a very pressing problem,<br>
because link layer security never mattered as much as security at<br>
higher layers.<br>
<br>
Besides, other link layer protocols such as 802.11 that are more<br>
popular (measured by nodes using them) and less secure (as commonly<br>
deployed) make the insecurity of PPP links moot. =A0What bad guy would<br>
bother attacking a PPP/DSL link when a radio can get bits on and<br>
off the same PPP link easier and with fewer traces?<br>
<br>
Link layer encryption, authentication, and authorization don&#39;t<br>
matter a lot if you have end-to-end confidentiality, authentication,<br>
authorization, non-repudiation, etc. =A0On the other hand, if you<br>
haven&#39;t secured things end-to-end, then link layer security is<br>
snake oil.<br>
<br>
If you&#39;ve the least connection to today&#39;s operational security<br>
community, you know that the worst that could happen with a link layer<br>
attack is trivial compared what happens now in higher layers. =A0Even<br>
if this WG could fix PPP security this decade, wouldn&#39;t the effort<br>
of the rest of the IETF in reviewing, advancing, and shuffling our<br>
documents be better spent in the higher layers? =A0Recall BPG security,<br>
what DigiNotar and Comodo prove about PKI (that we all knew many years<br>
ago), old style insecure DNS, DNSSEC vulnerabilities analogous to the<br>
PKI problems, the RIR issues, and so forth and so on and on.<br>
<br>
<br>
It would be nice to fix nasty messes such as PPPoE, but that ship<br>
has also sailed.<br>
<font color=3D"#888888"><br>
<br>
Vernon Schryver =A0 =A0<a href=3D"mailto:[email protected]">[email protected]=
</a><br>
</font><div><div></div><div class=3D"h5">__________________________________=
_____________<br>
Pppext mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/pppext" target=3D"_blank">=
https://www.ietf.org/mailman/listinfo/pppext</a><br>
</div></div></blockquote></div><br>

--20cf307d00d0877f3b04acca987c--

--===============8742350274276829483==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pppext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pppext

--===============8742350274276829483==--