[prev in list] [next in list] [prev in thread] [next in thread]
List: ipsec
Subject: [Ipsec] I-D ACTION:draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt
From: Tero Kivinen <kivinen () kivinen ! iki ! fi>
Date: 2006-10-05 9:15:13
Message-ID: 17700.52513.861679.673271 () fireball ! kivinen ! iki ! fi
[Download RAW message or body]
Internet-Drafts@ietf.org writes:
> Title : Extensions to IKEv2 to Support Header
> Compression over IPsec (HCoIPsec)
> Author(s) : R. Jasani, et al.
> Filename : draft-ietf-rohc-ikev2-extensions-hcoipsec-00.txt
> Pages : 15
> Date : 2006-9-29
Some comments:
> 3.1. Header Compression Scheme Negotiation
...
> Protocol ID (1 octet)
> If this notification concerns an existing SA, this field indicates
> the SA type. This field must contain either (2) to indicate AH or
> (3) to indicate ESP on the Child SA. For notifications that do
> not relate to an existing SA, this field must be sent as zero and
> ignored on receipt. This value must not be set to (1), since this
> refers to IKE_SA notifications. All other values for this field
> are reserved to IANA for future assignment.
The draft-eronen-ipsec-ikev2-clarifications-09.txt (now in the RFC
editor queue) states that:
> 7.8. Protocol ID/SPI fields in Notify payloads
...
> Since the main purpose of the Protocol ID field is to specify the
> type of the SPI, our interpretation is that the Protocol ID field
> should be non-zero only when the SPI field is non-empty.
I.e. as we do not have SPI in this HC_SUPPORTED notify the protocol ID
MUST be 0, not 1.
Also I think the Notify payload body should contain exactly one HC ID
and configuration parameters for that scheme, and instead of combining
all HC parameters inside that one notify add multiple notify payloads
each specifying exactly one HC scheme, and the priority order comes
from the order of notify payloads (similarly what MOBIKE does with the
ADDITIONAL_IP*_ADDRESS notifies, see RFC4621 section 6.3 for more
information about the description of the issue).
Also I do not understand why do you have HC ID twice, i.e. first the
current HC ID and then the next HC ID in the same block and then the
next block again repeats the HC ID (i.e. hopefully the same as the
Next HC ID as listed before) and so on. This makes implementations
harder as the implementator needs to check that those numbers match
and needs to decide what to do if they do not match (tear down IKE SA?
Ignore HC_SUPPORTED notify? etc).
So my proposal would be change the current format of :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID(0)! SPI Size(0) ! Notify Message Type (HC_SUPP) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC ID(X) | Next HC ID(Y) | HC Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ HC Scheme Configuration Parameters ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC ID(Y) | Next HC ID(0) | HC Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ HC Scheme Configuration Parameters ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
with multiple IKEv2 Notify payloads:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID(0)! SPI Size(0) ! Notify Message Type (HC_SUPP) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC ID(X) | HC Scheme Confuguration Parameters |
+-+-+-+-+-+-+-+-+ |
~ ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID(0)! SPI Size(0) ! Notify Message Type (HC_SUPP) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC ID(Y) | HC Scheme Confuguration Parameters |
+-+-+-+-+-+-+-+-+ |
~ ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this format there is no need to have separate HC Parameter Length
field, as the length can be seen from the notify payload length. This
also removes the double HC ID issue and is probably easier to
implement as IKEv2 implementations already know how to parse notify
payloads so they will do the parsing of that and just give the notify
data to the HC module.
I do not also understand the reason why we need to explicitly offer
NONE HC ID. Does that mean that if we do not offer it all packets MUST
have header compression enabled and cannot be sent without compression
at all? What should recipient do if it receives such packet without
header compression. If this is negotiated security parameter then it
should actually detect this as a violation of the security policy and
throw away of that packet, but I do not think we want to do that. If
recipient always needs to accept packets without header compression
then I do not think it is useful to even include NONE to the list at
all.
--
kivinen@safenet-inc.com
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic