Re: [pcp] Comparison of PCP authentication

[Yoshihiro Ohba <[e-mail]>]

Alper,

(2012/08/08 1:16), Alper Yegin wrote:
> Hi Yoshi,
> 
>>>>
>>>> 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.
>>>
>>>
>>> Those bits are reserved for "future."
>>> And because of this demux design, "now" we want to make sure no one will ever set bit#7.
>>
>> I think "no one will ever set bit#7" is too much restricted.
>>
>> Because of in-band key management, a bit in the PANA "Reserved" field
>> to be used for demultiplexing "over PCP port" can be meaningful only
>> when PANA message is carried "over the PCP port".   The bit could also
>> be used for demultiplexing other application carried over another port
>> if the other application allows to use the bit for demultiplexing
>> purpose as well.
> 
> 
> We can either say:
> 
> Bit#7 is reserved for use with PCP. (And it's always set to 0).

This is over-specified as I explained above.

> 
> Or,
> 
> When used over PCP port, Bit#7 is always set to 0.
> When used over other ports, its reserved for future use (as it currently is).
> 
> 
> Latter one is more conservative about bit usage, but a bit more cumbersome. Not sure which way to go.
> 

The latter one does not work.  Once we define some PANA bits for
in-band key management (for whatever application protocol), the same
bits cannot be used for future new PANA extensions commonly applicable
to both plain PANA and in-band PANA.  Therefore, the bits won't be
able to be marked as reserved any more once we give out.

This is what I think:

- Decide on how many bits (4 bits?) are needed from the 16-bit PANA
"Reserved" field for in-band key management.

- Write a new PANA I-D to allocate the in-band bits that are not bound
to any specific application protocol in the I-D.  Perhaps you and I
can work on this.

- Describe PCP-specific usage of the in-band bits in
draft-ietf-pcp-authentication.

> 
>>
>>  From PANA perspective, we can now allocate the whole 16-bit "Reserved"
>> PANA field for "in-band key management usage", and let each
>> application including PCP define how to demultiplex using the 16-bit.
>> I think this is a cleaner and extensible approach.
>>
> 
> We may not want to give up on the 16-bit space for encoding one type of usage (in-band). Let's think about this…..
> 

I agree with you that we don't need to give up on the whole 16-bit
space.  I think the top 4 bits should be sufficient as Margaret
mentioned.

Yoshihiro Ohba



> Alper
> 
> 
> 
> 
>> Yoshihiro Ohba
>>
>>
>>> What we need is to allocate that bit and state it's always set to 0. I don't think we need a separate RFC for this, this'd be the RFC that defines how PANA and PCP are used together.
>>>
>>> Alper
>>>
>>>
>>>
>>>
>>>
>>
> 
>