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

[Alper Yegin <[e-mail]>]

>    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.

That's an odd thing. EAP needs a lower-layer to get transported, as defined in RFC 3748. It's not going to fly on its own.

> 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.
> 

What's a "framework"? 

> 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.  

I'm confused. It is the EAP-over-PCP that's creating the additional layering, not PANA.
It's carrying equivalent of PANA over PCP (layering!) vs using PANA and PCP side-by-side.

> 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.
> 

Again, I'm confused. With PANA, you get re-use of spec, implementation, security analysis. 
Which one of these do you get with yet-to-be specified EAP-over-PCP?

> 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.
> 

I'm not surprised at all. Embedding a protocol inside another is never a drag-and-drop activity.


> 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.
> 

To have more clarity, we need to use more specific terms, such as end-point authentication, data origin authentication (integrity+replay protection), data confidentiality. 

With the mention of TLS, let me note that there are three distinct approaches:

1. Transport layer security (e.g., TLS)
TLS encapsulates the subject protocol
End-point auth, data origin auth, data confidentiality provided by TLS

2. Separate key management (e.g., IKE, EAP transports)
End-point authentication provided by the key management protocol
Data origin auth, data confidentiality provided by subject protocol using the keys from the key management protocol.

3. All-in-one (e.g., PPP, EAP-over-PCP)
End-point auth, data origin auth, data confidentiality provided by the subject protocol. 



> 
> 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.
> 

Is this an "issue"?

> 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.

I'll spin off a separate thread for this one.

Alper