Re: [pcp] Comparison of PCP authentication

[Margaret Wasserman <[e-mail]>]

Hi Alper,

Thanks for your help with this!  While it would work to demultiplex on the first byte, as you indicate, there is a bit more to defining a demultiplexing solution than this...

Since this is UDP, there is nothing that inherently binds the PANA authentication to a particular (set of) PCP request(s).  So, we will need to make sure that the information passed in the authentication option is sufficient for the sever to securely determine that the client sending a the PCP request is the same client that initiated the PANA exchange and vice versa, just as we would need to do if PANA and PCP were run on separate ports.  I don't think this will be difficult, we just need to make sure that we achieve it.

Do you know what existing PANA implementations will do if the "Reserved" field at the start of the packet is non-zero? 

We should also consider the trade-offs between a demultiplexing approach (which allows us to run PANA and PCP separately over a single port), and an encapsulation approach (PANA encapsulated in PCP).  A demultiplexing approach is somewhat cleaner, in that we can process the whole message as a PANA or PCP message.  But, the encapsulation approach would allow us to gain some optimization by piggy-backing the first (and possibly the final?) messages of the PANA exchange in the original PCP request (and response?) to cut down on the number of messages needed to create a secure mapping.  Since the PCP exchange may happen as part of client connection set-up (while a user is waiting), cutting down on the number of messages exchanged could be valuable.

As discussed at the PCP meeting in Vancouver, we will be writing up both of these approaches soon, for further discussion on an interim phone call.

Margaret


On Aug 6, 2012, at 3:43 PM, Alper Yegin wrote:

> 
> 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.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp