Re: [pcp] Comparison of PCP authentication

["Dan Wing" <[e-mail]>]

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