Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05: ESP Processing

[<[e-mail]>]

[e-mail] writes: 
>> New Section 3.4 
>> 
>> 3.4 Header Placement Using IPSec ESP Mode 
>> 
>>    IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303] and 
>>    is widely used.  Section 3.1.1 of [RFC4303] discusses placement of 
>>    Destination Options Headers. 
>> 
>>    The placement of PDM is different depending on if ESP is used in 
>>    tunnel or transport mode. 
>> 
>>    3.4.1 Using Transport Mode 
>> 
>>    Below is the diagram from [RFC4303] discussing placement of headers. 
>> 
>>    Note that Destination Options MAY be placed before or after ESP or 
>>    both.  In transport mode, PDM MUST be placed after the ESP header so 
>>    as not to leak information. 
>> 
>>                            BEFORE APPLYING ESP 
>> 
>>              --------------------------------------- 
>>        IPv6  |            | ext hdrs |    |      | 
>>              | orig IP hdr |if present| TCP | Data | 
>>              --------------------------------------- 
>> 
>>                            AFTER APPLYING ESP 
>>              --------------------------------------------------------- 
>>        IPv6  | orig |hop-by-hop,dest*,|  |dest|  |    | ESP  | ESP| 
>>              |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| 
>>              --------------------------------------------------------- 
>>                                          |<--- encryption ---->| 
>>                                          |<------ integrity ------>| 
>> 
>>              * = if present, could be before ESP, after ESP, or both 
>> 
>> 3.4.2 Using Tunnel Mode 
>> 
>>    Below is the diagram from [RFC4303] discussing placement of headers. 
>> 
>>    Note that Destination Options MAY be placed before or after ESP or 
>>    both in both the outer set of IP headers and the inner set of IP 
>>    headers. 
>> 
>>    In tunnel mode, PDM MAY be placed before or after the ESP header 
>>    or both. 
>> 
>>                              BEFORE APPLYING ESP 
>> 
>>            --------------------------------------- 
>>      IPv6  |            | ext hdrs |    |      | 
>>            | orig IP hdr |if present| TCP | Data | 
>>            --------------------------------------- 
>> 
>>                      AFTER APPLYING ESP 
>> 
>>            ------------------------------------------------------------ 
>>      IPv6  | new* |new ext |  | orig*|orig ext |  |    | ESP  | ESP| 
>>            |IP hdr| hdrs*  |ESP|IP hdr| hdrs *  |TCP|Data|Trailer| ICV| 
>>            ------------------------------------------------------------ 
>>                                |<--------- encryption ---------->| 
>>                            |<------------ integrity ------------>| 
>> 
>>            * = if present, construction of outer IP hdr/extensions and 
>>                modification of inner IP hdr/extensions is discussed in 
>>                the Security Architecture document. 

>For tunnel mode you could add text noting, that as the sgw will make 
>completely new IP packet, it means that PDM information for that 
>packet does not contain any information from the inner packet, i.e. 
>the PDM information will NOT be based on the TCP ports etc in the 
>inner header, but will be specific to the ESP flow. 

>If you want to see PDM information for the inner packet, the original 
>host sending the inner packet needs to put PDM header in the tunneled 
>packet, and then the PDM information will be specific for that TCP 
>stream. 

OK.

>So if the PDM header is part of "new ext hdrs*" then it specifies the 
>ESP flow, and it will not be end to end, it will only between SGSs. If 
>the PDM is part of the "orig ext hdrs*", then it will be end to end 
>PDM header, and ESP processing does not modify it at all. This 
>location is only place, where you can get end to end information about 
>the flow. 

>The first PDM header which is part of the ESP, will not separate TCP 
>flows at all, as it is for the ESP packets, thus it might not be that 
>useful, especially as there is no relation between the inbound ESP 
>packet and outbound ESP packet. The inbound ESP packet might be TCP 
>packet, and the tunneled packet is sent forward to the inner network, 
>and then the next outbound ESP packet might be from some completely 
>different host in different stream, and might be for example UDP DNS 
>packet. Having PDM information between those packets does not really 
>help debuggin at all.

I think the first PDM header is, of course, not as helpful as the first.
I suppose what one has is a sense of how that stack (server / client) is
responding to various requests.

I think that might be useful.  If one sees very good service at one time
and not so good service for others, then one knows that it is not the server
or client itself that is "hung".  If that makes sense.  

Or if there is a network issue to that device.  That is the kind of thing that
I get involved in often.

Nalini