Re: [Gen-art] Gen-art reiew of draft-ietf-rohc-ipsec-extensions-hcoipsec-05

[Elwyn Davies <[e-mail]>]

Ertekin, Emre [USA] wrote:
> Hi Elwyn,
>
> Sure, we can add pointers.  However, since all of the values are split amongst various RFCs, how about we point to the appropriate IANA registries.  
>   
(Sorry that should have been 'reply all')
Sounds like a good plan.

I promise not to have any more last minute thoughts. ;-)

Thanks,
Elwyn
> So, for the Profile identifiers, we would point to the registry at [http://www.iana.org/assignments/rohc-pro-ids/rohc-pro-ids.xhtml], and for the Integrity algorithms we can point to the Transform Type 3 - Integrity Algorithm Transform IDs registry at [http://www.iana.org/assignments/ikev2-parameters].
>
> R,
> Emre
>
>   
>> -----Original Message-----
>> From: Elwyn Davies [mailto:[e-mail]]
>> Sent: Monday, November 30, 2009 11:31 AM
>> To: Ertekin, Emre [USA]
>> Cc: General Area Reviwing Team; Mary Barnes; [e-mail];
>> [e-mail]; [e-mail]; Christou, Christos [USA]
>> Subject: Re: Gen-art reiew of draft-ietf-rohc-ipsec-extensions-
>> hcoipsec-05
>>
>> Hi.
>>
>> Last minute thought... the profile identifiers tie up with the profile
>> numbers in RFC 4996 and RFC 5225 - it would be worth noting that.  I
>> can't see where the authentication algorithm identifiers tie up with -
>> I
>> presume there must be some place these various algorithms are specified
>> for ROHC.  It ought to be referenced.
>>
>> Regards,
>> Elwyn
>>
>> Ertekin, Emre [USA] wrote:
>>     
>>> Hi Elwyn,
>>>
>>> Great.  I agree with both of your points.  I will make the updates to
>>>       
>> the draft.
>>     
>>> Once I make these changes, I will consider this thread/comment as
>>>       
>> resolved.
>>     
>>> BR,
>>> Emre
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Elwyn Davies [mailto:[e-mail]]
>>>> Sent: Monday, November 30, 2009 3:08 AM
>>>> To: Ertekin, Emre [USA]
>>>> Cc: General Area Reviwing Team; Mary Barnes; rohc-
>>>>         
>> [e-mail];
>>     
>>>> [e-mail]; [e-mail]; Christou, Christos [USA]
>>>> Subject: Re: Gen-art reiew of draft-ietf-rohc-ipsec-extensions-
>>>> hcoipsec-05
>>>>
>>>> Hi.
>>>>
>>>> This seems good to me.  One minor point on the ASN.1:  I think the
>>>> extra
>>>> 'rohc' piece should it be specified as 'OPTIONAL' so that not it
>>>> doesn't
>>>> have to be in every implementation - and should it come after the
>>>> tunnel
>>>> params as this change will alter the OID of tunnel params as it
>>>>         
>> stands
>>     
>>>> (if my understanding of ASN.1 is right)?
>>>>
>>>> Thanks.
>>>> Elwyn
>>>>
>>>> Ertekin, Emre [USA] wrote:
>>>>
>>>>         
>>>>> Hi Elwyn,
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>>>> SPD additions:
>>>>>>>> In Section 2.1 some additional fields to be added to the SPD
>>>>>>>> Processing component are described informally.  RFC 4301 which
>>>>>>>>                 
>> has
>>     
>>>>>>>>                 
>>>>>> the
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>> unmodified version of the  Processing component also has a
>>>>>>>>                 
>> formal
>>     
>>>>>>>>                 
>>>>>> ASN.1
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>> description.  I think this document needs an updated  ASN.1
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>> desciption
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>> also.
>>>>>>>>
>>>>>>>> Further the description talks about adding 'processing info'
>>>>>>>>
>>>>>>>>                 
>>>> fields
>>>>
>>>>         
>>>>>> if
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>> the
>>>>>>>> 'processing info field is set to PROTECT'.  Although this partly
>>>>>>>> reflects the
>>>>>>>> wording in the body of RFC 4301, it is rather confusing when
>>>>>>>>
>>>>>>>>                 
>>>> looking
>>>>
>>>>         
>>>>>> at
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>> the
>>>>>>>> ASN.1.  The wording of para 3 of S2.1 might be better as:
>>>>>>>>   If the SPD entry is an IPsecEntry (to PROTECT traffic) then
>>>>>>>>                 
>> the
>>     
>>>>>>>> Processing
>>>>>>>>   item of the IPsecEntry must be extended with the following
>>>>>>>>
>>>>>>>>                 
>>>> items:
>>>>
>>>>         
>>>>>> On refelection, I agree that using IPsecEntry in s2.1 wouldn't be
>>>>>> appropriate.  However I think the wording could still be improved.
>>>>>> Retry:
>>>>>>    If the processing action associated with the selector sets is
>>>>>> PROTECT, then the processing info must be
>>>>>>    extended with the following ROHC channel parameters:
>>>>>>
>>>>>>
>>>>>>             
>>>>> OK; sounds good!
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>>> A while back, we were thinking of adding ASN.1 notation to the
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> draft...however we opted not to.  This is because Appendix C in
>>>>>>             
>> RFC
>>     
>>>>>> 4301 is only an example ASN.1 definition of a SPD and is referred
>>>>>>             
>> to
>>     
>>>> as
>>>>
>>>>         
>>>>>> "merely illustrative".  Since our extensions would've expanded
>>>>>> upon/augmented this non-normative text, we decided to leave it
>>>>>>             
>> out.
>>     
>>>>>> Sure, it is illustrative, but it also seems to have specified a
>>>>>>
>>>>>>             
>>>> fully
>>>>
>>>>         
>>>>>> qualified OID.  This indicates to me that at least some people may
>>>>>>
>>>>>>             
>>>> be
>>>>
>>>>         
>>>>>> using this as an access mechanism for the SPD. In that case
>>>>>>
>>>>>>             
>>>> formally
>>>>
>>>>         
>>>>>> specifying the ASN.1 would be highly desirable even if it is not
>>>>>> normative.  Doubtless there are other people who know if the SPD
>>>>>>             
>> is
>>     
>>>>>> accessed this way (e.g. as a MIB) even if I don't.
>>>>>>
>>>>>>
>>>>>>             
>>>>> OK.  We developed the ASN.1 representation of the ROHC parameters
>>>>>           
>> and
>>     
>>>> plan to incorporate it as an Appendix to the draft.  The text reads
>>>>         
>> as
>>     
>>>> follows:
>>>>
>>>>         
>>>>> Appendix A.  ASN.1 representation for ROHCoIPsec
>>>>>
>>>>>    This appendix is included as an additional way to describe the
>>>>>    ROHCoIPsec parameters that are included in the IPsec SPD.  It
>>>>>           
>> uses
>>     
>>>>>    portions of the ASN.1 syntax provided in Appendix C of RFC 4301
>>>>>    [IPSEC].  In addition, several new structures are defined.
>>>>>
>>>>>    This syntax has been successfully compiled.  However, it is
>>>>>           
>> merely
>>     
>>>>>    illustrative and need not be employed in an implementation to
>>>>>
>>>>>           
>>>> achieve
>>>>
>>>>         
>>>>>    compliance.
>>>>>
>>>>>    The "Processing" data structure, defined in Appendix C of RFC
>>>>>
>>>>>           
>>>> 4301,
>>>>
>>>>         
>>>>>    is augmented to include a ROHC parameters element as follows:
>>>>>
>>>>>          Processing ::= SEQUENCE {
>>>>>              extSeqNum   BOOLEAN, -- TRUE 64 bit counter, FALSE 32
>>>>>
>>>>>           
>>>> bit
>>>>
>>>>         
>>>>>              seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate &
>>>>>
>>>>>           
>>>> audit
>>>>
>>>>         
>>>>>              fragCheck   BOOLEAN, -- TRUE stateful fragment
>>>>>           
>> checking,
>>     
>>>>>                                   -- FALSE no stateful fragment
>>>>>
>>>>>           
>>>> checking
>>>>
>>>>         
>>>>>              lifetime    SALifetime,
>>>>>              spi         ManualSPI,
>>>>>              algorithms  ProcessingAlgs,
>>>>>              rohc        RohcParams,
>>>>>              tunnel      TunnelOptions OPTIONAL
>>>>>          }
>>>>>
>>>>>    The following data structures describe these ROHC parameters:
>>>>>
>>>>>        RohcParams ::= SEQUENCE {
>>>>>            rohcEnabled         BOOLEAN, --  TRUE, hdr compression
>>>>>           
>> is
>>     
>>>> enabled
>>>>
>>>>         
>>>>>                                         -- FALSE, hdr compression
>>>>>           
>> is
>>     
>>>> disabled
>>>>
>>>>         
>>>>>            maxCID              INTEGER (0..16383),
>>>>>            mrru                INTEGER,
>>>>>            profiles            RohcProfiles,
>>>>>            rohcIntegAlg        RohcIntegAlgs,
>>>>>            rohcIntegICVLength  INTEGER
>>>>>            }
>>>>>
>>>>>        RohcProfiles ::= SET OF RohcProfile
>>>>>
>>>>>        RohcProfile ::= INTEGER {
>>>>>            rohcv1-rtp           (1),
>>>>>            rohcv1-udp           (2),
>>>>>            rohcv1-esp           (3),
>>>>>            rohcv1-ip            (4),
>>>>>
>>>>>            rohcv1-tcp           (6),
>>>>>            rohcv1-rtp-udpLite   (7),
>>>>>            rohcv1-udpLite       (8),
>>>>>
>>>>>            rohcv2-rtp         (257),
>>>>>            rohcv2-udp         (258),
>>>>>            rohcv2-esp         (259),
>>>>>            rohcv2-ip          (260),
>>>>>
>>>>>            rohcv2-rtp-udpLite (263),
>>>>>            rohcv2-udpLite     (264)
>>>>>            }
>>>>>
>>>>>        RohcIntegAlgs ::= SEQUENCE {
>>>>>            algorithm   RohcIntegAlgType,
>>>>>            parameters  ANY -- DEFINED BY algorithm -- OPTIONAL }
>>>>>
>>>>>        RohcIntegAlgType ::= INTEGER {
>>>>>            none                    (0),
>>>>>            auth-HMAC-MD5-96        (1),
>>>>>            auth-HMAC-SHA1-96       (2),
>>>>>            auth-DES-MAC            (3),
>>>>>            auth-KPDK-MD5           (4),
>>>>>            auth-AES-XCBC-96        (5),
>>>>>            auth-HMAC-MD5-128       (6),
>>>>>            auth-HMAC-SHA1-160      (7),
>>>>>            auth-AES-CMAC-96        (8),
>>>>>            auth-AES-128-GMAC       (9),
>>>>>            auth-AES-192-GMAC      (10),
>>>>>            auth-AES-256-GMAC      (11),
>>>>>            auth-HMAC-SHA2-256-128 (12),
>>>>>            auth-HMAC-SHA2-384-192 (13),
>>>>>            auth-HMAC-SHA2-512-256 (14)
>>>>>            --  tbd (15..65535)
>>>>>            }
>>>>>
>>>>> I think that does it!  Let me know if this looks good to you.
>>>>>
>>>>> V/R,
>>>>> Emre
>>>>>
>>>>>
>>>>>           
>
>