[rohc] RE: draft-ertekin-rqts-hcoipsec-01.txt

["Jasani Rohan" <[e-mail]>]

Stephen:
I have detailed below, how we envision inbound and outbound processing
to work.  These explanations should answer the questions posed in
previous emails.  Please provide us with feedback and comments in
regards to the explanations below. Thanks

SA ESTABLISHMENT:
Currently, we are writing a draft detailing how IKE will need to be
extended to support HC scheme and HC parameter negotiation.  In
addition, the draft will detail the appropriate HC "data items" that are
associated to an SA.  Specifically, the "HC Scheme" data item will
indicate whether HC will be applied SA and if applied, which HC scheme
will be used (i.e. NO COMPRESSION, ROHC, ECRTP, IPHC).  "HC Scheme" is
used during processing to determine whether a packet should be handed to
the HC process or not and if HC is applied, to which HC process (i.e.
ROHC, ECRTP, etc...) to hand the packet to.

GENERAL OPERATION
All traffic associated to an SA will either be compressed or not
compressed.  Based on which types of traffic would like to be compressed
(established through policies)* and the types of traffic  (i.e. IP/TCP,
IP/UDP, IP/UDP/RTP) that can be compressed by the HC schemes on the
IPsec devices, values for standard selectors ("Next Layer Protocol" &
"Port") will be chosen to filter out the traffic that needs compression
(additional selector values will be used in conjunction to define the
traffic that is afforded security by the SA). 

*not all traffic benefits from HC and most HC schemes only support
compression of certain types of traffic (i.e. IP/UDP/RTP, etc...)

OUTBOUND PROCESSING:
Traffic will be mapped to an SA based on selector values (including
"Next Layer Protocol" & "Port").  The traffic is encrypted/authenticated
according to the SA.  Then...
        - If the "HC Scheme" data item (included with the SAD entry)
indicates a compression scheme, then the traffic is handed to the HC
process which will compress the traffic and then hand it back to IPsec
for further processing.
        - If the "HC Scheme" data item indicates NO Compression, then
the traffic continues through the normal IPsec processing.

INBOUND PROCESSING:
a) After an inbound packet passes through AH/ESP processing (Step 4 on
Page 60 of I-D 2401bis) the packet can take one of either two routes:
        -If the SA indicates HC was applied, then the packet is handed
to the HC process for decompression.  Once the packet is decompressed it
is passed to Step "b".
        -If the SA indicates HC was NOT applied, then proceed to Step
"b".
Note: Based on information retrieved from the SAD entry in Step 3a
(Page 59 of I-D 2401bis) it can be determined whether traffic traversing
the SA is compressed or not compressed, as this indication is associated
to an SA

b) Continue regular processing described in Step 4 on Page 60 of I-D
2401bis.  Specifically "Then match the packet against the inbound
selectors identified by the SAD..."

COMMENTS:
- Each SAD entry will need to have additional information related to HC,
where would we need to specify that information (i.e. HCoIPsec draft,
IPsec standard, etc...) ?
- As of right now, we are not planning on using the ROHC uncompressed
profile to carry uncompressed traffic on a ROHC-enabled SA, as this
profile adds 1 or 2 bytes of overhead to each uncompressed packet.  This
decision will prevent the need to multiplex compressed and uncompressed
traffic over a single SA and it allows all traffic traversing an SA to
be processed in the same manner. 
- Only ECRTP requires an additional packet type field, which will be
added as an extension to the ECRTP header (same approach used in ECRTP
over MPLS I-D draft-ietf-avt-hc-mpls-reqs-03.txt).  ROHC has
self-describing headers, thus it does not require an additional header.
Therefore, additional protocol numbers should not be required.

Rohan Jasani
Booz | Allen | Hamilton
703.377.4641 (office)
832.452.3241 (mobile)

 

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]] 
> Sent: Friday, June 24, 2005 9:58 AM
> To: [e-mail]
> Cc: Russ Housley; Jasani Rohan; Christou Chris; Ertekin Emre; 
> [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; Stephen Kent
> Subject: RE: draft-ertekin-rqts-hcoipsec-01.txt
> 
> Lars-Erik,
> 
> >...
> >
> >I do not mean that you turn off ROHC, but what if you get 
> more flows to 
> >handle than you have negotiated support for, then there is a ROHC 
> >profile that can send the packets "ROHC-encapsulated"
> >but with uncompressed headers. This profile can also be used 
> for e.g. 
> >packet flows using "new" transport protocols not yet 
> supported by ROHC.
> 
> I'm not sure I understand your comment above. When we create 
> an SA we define the range of traffic flows that it will 
> accommodate, based on the 5 traffic selector types that IPsec 
> uses to distinguish traffic (S/D IP address, protocol, and 
> S/D ports, if applicable). Only traffic consistent with the 
> traffic selector values specified for an SA can be carried on 
> that SA, period.
> 
> >In the draft, I saw multiplexing of compressed and 
> uncompressed header 
> >packets, and therefore I wanted to point out that this 
> multiplexing can 
> >be done with ROHC mechanisms, thereby avoiding the 
> unnecessary overhead 
> >from an additional multiplexing mechanism.
> 
> The draft you cited is an individual submission. It was not 
> coordinated with the IPsec WG. It addresses the IPsec 
> requirement for inbound traffic demuxing by adding another 
> layer of header, but this has the potential to consume too 
> many protocol numbers, and thus may not be acceptable. There 
> is also the issue that mixing compressed and uncompressed 
> traffic on the same SA, and distinguishing them via the 
> presence of an added protocol layer may cause problems for 
> inbound processing, because support for nested processing is 
> an optional feature for IPsec implementations.
> 
> >...
> >I do not understand this comment. If you set up a tunnel 
> where you want 
> >to apply HC, you intend to compress all packets, right? Then 
> you will 
> >only have ROHC-packets in the tunnel, no packet type 
> identifier is then 
> >needed.
> 
> See section 5.2 of 2501bis (now in the RFC editor's queue) 
> for an explanation of how inbound traffic is processed in 
> IPsec. It may be OK to handle HC-compressed traffic as you 
> suggest, but it is not immediately clear that this will work, 
> because of the underlying assumptions that IPsec makes in 
> support of access control.
> 
> Steve
> 

_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc