RE: [rohc] Comments on ROHC IKEv2 extensions

["Pezeshki, Jonah" <pezeshki_jonah at bah.com>]

Pasi,

Thank you for providing comments to our pending Internet Draft
(draft-ietf-rohc-ikev2-extensions-hcoipsec-02).  Please find our
response to your comments below (comments inline).

Jonah Pezeshki
Consultant
Booz | Allen | Hamilton
(703) 984-0810

-----

Subject: [rohc] Comments on ROHC IKEv2 extensions

Comments on draft-ietf-rohc-ikev2-extensions-hcoipsec-02:

1) The document doesn't really describe how the negotiation works. For
example, can CREATE_CHILD_SA request contain multiple ROHC_SUPPORTED
payloads? Is the responder required to pick one of them exactly, or is
it allowed to adjust the parameters somehow? E.g. if initiator sends
MAX_CID of 100, is the responder allowed to lower this to 99? What about
the other fields? What you're supposed to do when you e.g. receive a
suboption you don't recognize?

-I have updated the drafts to more specifically define the nature of the
negotiation.  In answer to the posed questions: an exchange may only
contain a single ROHC_SUPPORTED payload (additional ROHC_SUPPORTED
payloads are ignored upon receipt); The responder may adjust the
parameters so that both the initiator and responder will support the
selected value (i.e., if the initiator proposed a MAX_CID value of 15,
and the Responder only supports a MAX_CID of 13, the selected MAX_CID
value will be 13); if the initiator proposed a profile that is not
supported by the responder, this profile will not be supported by the
created Child SA.

2) I'd recommend NOT repeating the generic definition of Notify payload;
the description doesn't 100% match RFC 4306, and it's redundant anyway.

In other words, replace the text by "The Notify Message Type for
ROHC_SUPPORTED is TBD-BY-IANA. The Protocol ID and SPI Size fields are
set to zero.  The RoHC configuration parameters are listed in the
notification data in the following format:"

-I have modified the text, and removed redundant text.  Instead, I
simply refer to RFC4306.

3) Why does the notification data include ROHC PARAMETERS LENGTH?
(the Notify payload already includes a length field, so this seems
redundant)

-Thank you for catching this oversight.  I have removed this field from
the ROHC_SUPPORTED Notify payload.

4) In section 2, is the intent to define a new suboption space, or reuse
the suboption space from RFC 3241? In the former case, IANA
considerations are needed; in latter case, the text should not repeat
the definitions, but just cite RFC 3241.

-I have adjusted this section to simply refer to the RoHC profiles, as
opposed to "suboptions", thus bringing it more inline with the RoHC
framework.  In addition, I refer to both RFC3095 and
draft-ietf-rohc-rfc3095bis-rohcv2-profiles-01 in this section, instead
of repeating text from other drafts.

5) Section 4 (IANA considerations): There are two kinds of IKEv2 notify
messages (error and status); this section should tell IANA which kind of
number to allocate (status is the right one here).

-The IANA Considerations section has been updated to indicate that our
Notify Message is a Status Type.

6) In bit diagrams, replace this
    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 with
this
                        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

-This has been corrected in our diagram.

7) In reference [ROHCPROF], the URL doesn't work.

-It turns out that this reference had expired.  We have since replaced
it with a different, more recent reference.

_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc