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

["Laganier, Julien" <[e-mail]>]

Hello again,

Thought that maybe making my question a bit more specific would help: 

So, why don't you simply define a UDP encapsulation to ESP, instead of duplicating ESP functionality into your framework?

--julien

Laganier, Julien wrote:
> 
> 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" <[e-mail]>
> 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mext
> >
> > _______________________________________________
> > MEXT mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mext
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext