Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec

Few things. The draft already states that "The Padding, Pad Length, Next
Header and ICV fields follow the rules of Section 2.4 to 2.8 of [RFC4303]
unless otherwise stated in this document." So, we follow the ESP format
but feel no shame on changing it if we see a reason to do so.

The reason why we chose to do it like this was two fold: 1) some ciphers
etc when used would need ~equivalent encapsulation anyway. 2) if we had
come up with our very own format the question on the list would have
been "why not using RFC4303 encapsulation format". Actually.. the latter
already happened offline.

- Jouni

On Jan 26, 2011, at 12:48 AM, Laganier, Julien wrote:

> Hi Raj,
> 
>> Inline:
>> 
>> On 1/24/11 3:58 PM, "ext Arnaud Ebalard" <arno@natisbad.org> wrote:
>> 
>>> 
>>> To me, what the draft describes is a patchwork based on MIPv6, ESP and
>>> TLS. Instead of building on top of those protocols (read modularity
>> and
>>> interoperability), it reuses (hijacks) various blocks of associated
>>> standards in a non-modular way. For instance, one has to reimplement
>> ESP
>>> in userspace to support the protocol.
>> 
>> We are specifying an encapsulation method in the I-D. To say that one
>> has to reimplement ESP in userspace is incorrect.
> 
> The encapsulation format you have in the I-D is:
> 
> 0                   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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                                                               |
> :         IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya)        :
> |                                                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                                                               |
> :            UDP header (src-port=Xp,dst-port=Yp)               :
> |                                                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
> |PType=8|                    SPI                                | ^Int.
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
> |                      Sequence Number                          | |ered
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
> |                    Payload Data* (variable)                   | |   ^
> :                                                               : |   |
> |                                                               | |Conf.
> +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
> |               |     Padding (0-255 bytes)                     | |ered*
> +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
> |                               |  Pad Length   | Next Header   | v   v
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
> |         Integrity Check Value-ICV   (variable)                |
> :                                                               :
> |                                                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>       Figure 7: UDP Encapsulated Binding Management Message Format
> 
> Which looks like a copy/paste of the ESP specification [RFC4303]:
> 
> 0                   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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
> |               Security Parameters Index (SPI)                 | ^Int.
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
> |                      Sequence Number                          | |ered
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
> |                    Payload Data* (variable)                   | |   ^
> ~                                                               ~ |   |
> |                                                               | |Conf.
> +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
> |               |     Padding (0-255 bytes)                     | |ered*
> +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
> |                               |  Pad Length   | Next Header   | v   v
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
> |         Integrity Check Value-ICV   (variable)                |
> ~                                                               ~
> |                                                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>            Figure 1.  Top-Level Format of an ESP Packet
> 
> 
> So the question is: Is your intent to provide a UDP encapsulation format for the already specified ESP protocol, or to provide an alternative encapsulation format to ESP?
> 
> --julien
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext