Re: [pcp] Comparison of PCP authentication

[Alper Yegin <[e-mail]>]

PANA:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |        Message Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Flags             |         Message Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Session Identifier                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  AVPs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Reserved

      This 16-bit field is reserved for future use.  It MUST be set to
      zero and ignored by the receiver.




PCP:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Version = 2  |R|   Opcode    |         Reserved              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                 Requested Lifetime (32 bits)                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |            PCP Client's IP Address (128 bits)                 |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) Opcode-specific information            :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     :                                                               :
     :             (optional) PCP Options                            :
     :                                                               :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


First octet can be used for demux'ing.

Alper





On Aug 6, 2012, at 9:01 PM, Dan Wing wrote:

>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Alper Yegin
>> Sent: Thursday, August 02, 2012 2:31 PM
>> To: [e-mail]
>> Subject: [pcp] Comparison of PCP authentication
>> 
>> http://www.ietf.org/proceedings/84/slides/slides-84-pcp-10.pdf
>> 
>> Ah, isn't it odd that this beauty contest is run by one of the
>> contestants? This material should have been prepared and presented by a
>> neutral party.
>> 
>> One important question: With this proposal, are the authors advocating
>> each protocol should come with their own in-band key management, more
>> specifically embedding an EAP transport?
>> 
>> 
>>> what's the big deal of using the same port vs different port? Is
>> jamming all in the same port is a benefit?
>> 
>>> "TLS is in-band"
>> 
>> - There's standalone use of TLS as "a separate" KMP. RFC 5705 is driven
>> by the fact that some other protocols need to use TLS as a "separate
>> KMP".
>> - TLS is basically "transport layer security", something that sits
>> below the protocol one would be trying to secure. We are not doing
>> that.
> 
> To throw another TLS thing into the mix:
> 
> DTLS-SRTP [RFC5764] uses the (D)TLS handshake to encrypt SRTP and is
> pretty well aligned with what we want for PCP -- we want a key
> exchange and then run the PCP protocol natively.  DTLS-SRTP has a 
> normal DTLS handshake, followed by SRTP packets that appear normal 
> on the wire (that is, the packets are RFC3711 packets which have
> their RTP headers in the clear).  It does this over the same socket,
> because the first byte indicates if the packet is DTLS, SRTP, or
> STUN (ICE), http://tools.ietf.org/html/rfc5764#section-5.1.2.
> 
> At the meeting, I suggested we consider if PANA and PCP could
> be similarly demux'd.  Stuart suggested using some sort of GRE-
> like header if they cannot be demux'd.  Either approach would 
> eliminate one of the objections of PANA, specifically its use 
> of a separate port.
> 
> -d
> 
> 
> 
>>> are the EAP and PCP state machines compatible? If marrying two
>> protocols, one needs to pay attention to this. This was one of the
>> reasons why EAPoDHCP did not work.
>> 
>>> Does the EAP-over-PCP satisfy the "EAP lower layer requirements" as
>> stated in RFC 3848? I had asked this question but don't remember seeing
>> any response.
>> 
>>> "Possible in-band optimization". Is this documented anywhere? It's
>> not easy to understand how it works by looking at this slide.
>> 
>>> PANA RFC 5191 was published in 2008, not 2011. It's adopted by Zigbee
>> IP, ETSI TISPAN, and also ETSI M2M. Aside from two open-source
>> implementations, multiple commercial implementations have successfully
>> passed interop events in Zigbee Alliance.
>> 
>>> 
>> 
>> *	Need to specify the portions of PANA that don't need to be
>> implemented
>> 
>> 	in a PCP PANA Client and Server (such as IP Address
>> reconfiguration)
>> 
>> 
>> 	>> this is just a single bit flag. We don't use it, and that's
>> all we need to do about it.
>> *	Need to specify/describe interface between PANA and PCP elements
>> 
>> 	>> this is an implementation issue, like how the other spec
>> implementors would need to define the interface between the EAP and PCP
>> for passing keys, etc.
>> 
>> *	Need to specify how the PANA client finds the correct PANA Server
>> for PCP Authentication (may be passed from PCP client?)
>> 
>> 	>> PCP server the the PAA are the same node.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
>