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

Hi Jouni,

I understand you "follow the ESP format but feel no shame on changing it if we see a reason to do so", but I am (shamelessly ;) wondering about the actual reason to do so, as per one of the famous Architectural Principles of the Internet documented in RFC 1958: 

   3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

Would you mind enlightening us?

--julien

jouni korhonen wrote:
> 
> 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" <[email protected]> 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/mext
> 
> _______________________________________________
> MEXT mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mext