[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rohc] Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec

Hi Pasi,

> Carsten Bormann wrote:
>
> > > OK, let me phrase my question in another way: why does the spec
> > > contain a feature that does not really work? (Even as optional
> > > feature?)
> >
> > Well, it actually does work.
> >
> > RFC 4224, section 5.2.1 tells us that when a channel is reordering
> > and you don't notice, packets will be lost.  Now IPsec is a strange
> > animal: It is reordering, but the order can be reconstructed from
> > the sequence number.  So a reassembler could (here really: SHOULD)
> > use that to avoid stitching together packets in the wrong order and
> > then discarding them.
>
> Well, the current drafts don't specify any such behavior, so the
> feature as it's currently written does not work. (Also, using the
> ESP/AH sequence number this way would be very unusual -- there
> might be some complications...)

If we include text that states this behavior, does this address your concern?

FWIW, I could also think of deployment scenarios where packet
reordering is minimal (e.g., ROHCOIPsec is instantiated over a single
[bandwidth constrained] link).  Such scenarios may not even require
the use of the ESP/AH sequence number to reconstruct ROHC segments.

Best Regards,
Emre

> Best regards,
> Psai
>
> _______________________________________________
> Rohc mailing list
> Rohc at ietf.org
> https://www.ietf.org/mailman/listinfo/rohc