Re: [pcp] Comparison of PCP authentication

[Yoshihiro Ohba <[e-mail]>]

RFC5191-conformant PANA implementations will ignore the "Reserved"
field.

If we specify a new use of PANA "Reserved" field, it cannot be an
Errata because it is not a specification error.  It needs to be a new
RFC that updates RFC 5191.

On the other hand, if we update RFC 5191 (in which WG?), then we
probably need to think more generally so that the update is beneficial
not only for PCP but also other protocols (such as STUN?) that can
potentially benefit from PANA-based in-band key management.

Yoshihiro Ohba

(2012/08/07 6:19), Dan Wing wrote:
>> -----Original Message-----
>> From: Margaret Wasserman [mailto:[e-mail]]
>> Sent: Monday, August 06, 2012 1:03 PM
>> To: Alper Yegin
>> Cc: Dan Wing; [e-mail]
>> Subject: Re: [pcp] Comparison of PCP authentication
>>
>>
>> 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?
> 
> Also, if an update to PANA allows 0b00000010 in that first octet, we will
> have a problem.  It would be safer if we assign the last two bits in that
> first octet of PANA to must-be-zero.  Perhaps via an Errata against the PANA
> spec, if we decide this is the best solution.
> 
>> 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.
> 
> How many messages are we talking about (5?), and how much reduction
> could we see (reduction from 5 to 3??).
> 
>> 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.
> 
> Looking forward to that.
> 
> -d
> 
> 
>> 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:pcp-
>> [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
>>
>>
> 
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp
>