Re: [pcp] [ Side-by-side or nested protocols

[Sam Hartman <[e-mail]>]

    >> +1 all I have seen so far is very complex for simple
    >> authentication of pcp. Let's embed it into pcp.
    >> 

    >> 
    >> I've been following this discussion and my preference would be to
    >> avoid having a design that requires a 'control protocol' between
    >> PCP and something else. We should reuse other IETF standards
    >> whenever possible but I would prefer everything to be part of a
    >> single protocol.

    Alper> This is so un-IETF to me. Here we have two distinct pieces of
    Alper> work (PCP and key management), that can be satisfied using
    Alper> two protocols, we are talking about cobbling them together.
    Alper> Like that was done in the PPP-era, and like it's done in GTP
    Alper> (of 3GPP). Lot of pain with both...  I'd understand how other
    Alper> SDOs would think that way, but their priorities are
    Alper> different. But for IETF, we design protocols, and cobbling up
    Alper> protocols unnecessarily gets in the way of modularity, which
    Alper> is very essential to IETF. Right?

Hi.
I haven't been working in the internet area that long, but I have been
working in the security area of the IETF and following the apps area's
security for a while.
I think  I have some experience with what's ietf and un-ietf in those
contexts.

There are two related questions here:

1) To what extent should security frameworks be re-used.

2) Whether key management should run in-band with the managed protocol.

Both of these issues have been hotly discussed.  There was actually an
IAB document--I think draft-iab-authmech or similar--that tried to rule
out any stacking of frameworks.  For example you could not use GSS-API
within SASL or EAP within PANA in a context where both were appropriate.
This generated rather a lot of comment, and it doesn't look like that
document was ever published as an RFC in part because the IAB was having
trouble getting consensus around the strong negative statements against
frameworks.

While I think that document went too far, the general concerns about
protocol layering it raised are real.  Additional protocol layers does
add all the forms of complexity that Wim discusses.  If you get re-use
of code or re-use of platform infrastructure then it can be worth that
additional complexity.  If you get re-use of security analysis then it
can be worth the complexity.

The question of in-band vs out-of-band has also been a hot question in
the security area. The most recent huge instance of that discussion I'm
aware of was the KARP working group.
Many security participants were arguing that tight integration of key
management into routing protocols would ease security analysis and make
it much more likely that we got things right.
In that instance, the  implementor community for the routing protocols
said that tight integration (in-bind) was an unacceptable implementation
strategy for reasons specific to the routing protocols.

Really, there are a lot of factors to consider; let me give you a few
examples.

Many applications have decided that authentication needs to be tightly
integrated but that confidentiality and integrity should be re-used from
TLS at arms length. These include IMAP, SMTP, LDAP, POP, XMPP and
HTTP. Several of these have a seldom-used but sometimes important
facility to more tightly integrate confidentiality and integrity. All
protocols are run in-band with encapsulation.


Ssh designed ssh-specific protocols for everything and runs everything
in-band.

IPsec uses an out-of-band separate key-management protocol.

Network access uses EAP often as a out-of-band key management protocol
with a separate security association protocol.

    >> Having a separate protocol would mean significant more test and
    >> effort for productization due to interactions, new CLIs,
    >> unforeseen state machine issues, etc.

    Alper> Just the opposite.  Inventing new EAP-over-UDP as part of PCP
    Alper> is a brand-new design with brand-new code. PANA is a standard
    Alper> with multiple interoperating implementations.  It's obviously
    Alper> more stable then the to-be-designed EAP-over-UDP/PCP.

I actually agree with Wim.
I've seen a lot of complexity gluing protocols together.
Even given that I do tend to be a fan of security frameworks, but I have
to admit that there are huge costs.
If there is not a strong value proposition in terms of new capabilities
users get, it may not be worth it.

    Alper> State machines is one of the issues with cobbling up
    Alper> protocols. Two separate protocols, living side by side, the
    Alper> state machines have nothing to conflict.

    Alper> If you put on inside the other, then problems arise.

Actually,  state machine alignment simply gets messy.
As you point out you need to deal with the fact that the direction is
different for PCP and EAP.

However, in the demultiplexing case, we also have state machine issues.
On the client, the state machine now needs to wait while authentication
is happening.
That is we're introducing a waiting-for-PANA state into the PCP client.

Also, I've seen complex interactions between protocol state machines in
distributed systems.  The first time I ran into state machine issues was
a distributed filesystem protocol called AFS. There were two very
modular protocols, one for metadata access and one for accessing files.
Unfortunately, they could interact with each other and delays in the
metadata protocol could cause ever-increasing delays in the file service
protocol.

That was far more painful to debug than a single integrated protocol
would have been.

    Alper> And I have yet to hear someone saying yes EAP-over-PCP
    Alper> satisfies the EAP lower layer requirements. I had raised this
    Alper> issue 3 times, and don't see anyone doing the work. It's not
    Alper> as simple as defining a container to ship EAP payloads back
    Alper> and forth.


We've made a specific proposal that we believe satisfies the
requirements of an EAP lower layer.  We'd certainly appreciate your
technical comments on that proposal.  If we missed something please let
us know.