Subject: Re: [lp-wan] WGLC on SCHC for IPv6 and UDP

From: Stephen Farrell <[email-masked]>
Date: Fri, 5 Jan 2018 17:04:08 +0000

Hiya,

I had a read of this and it seems to me to be generally
ready (though I've not written code so take that opinion
for what it's worth:-).

I've two comments:

1. Has anyone spent a bit of time trying to figure out
if there's a zipbomb [1] like attack that could be tried
based on the fragmentation scheme, possibly in some lower
layer specific manner? I couldn't see one immediately but
do wonder if someone clever might. If we did think there's
some possible concern there I wonder if it'd be worth
including some belt-and-braces constraints in the text,
e.g. maybe something like "never re-construct a packet
bigger than some configured size (with 1500 bytes as a
good generic default)"?

2. I wondered if there'd be a benefit in having a DNS
oriented equivalent for the AppIID construct here?
The idea would be to provide a way for a small device
to say "send this to <fqdn>" just once and for the
g/w to do the DNS lookup for that and construct the
IP packets accordingly. (So the g/w might need to tell
the device which address it's using.) There'd likely
be more work needed for such a scheme and it'd need
to work with load balancing of various kinds so even
if this is a good idea it might be better handled as
a separate draft. But I reckon some such scheme might
be useful as doing DNS on the devices won't happen,
and provisioning the IP addresses of the applications
doesn't seem that good an idea either.

Cheers,
S.

[1] https://en.wikipedia.org/wiki/Zip_bomb

On 12/22/2017 04:19 PM, Pascal Thubert (pthubert) wrote:
> Dear WG:
> 
> 
> 
> As discussed during the last interim, we are starting a WGLC on the "LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP" document:
> 
> https://datatracker.ietf.org/doc/draft-ietf-lpwan-ipv6-static-context-hc/
> 
> 
> 
> This is a fundamental work for the WG, so please, DO review the document and DO provide your comments and remarks if you see any issues.
> 
> 
> 
> In order to cover the season break, this WGLC will end in three+ weeks, on January 15th, 2018, 23h55 CEST, right before our next interim meeting.
> 
> 
> 
> Best,
> 
> Pascal and Alexander
> 
> 
> 
> 
> _______________________________________________
> lp-wan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lp-wan
> 

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

---

From: Laurent Toutain <[email-masked]>
Date: Wed, 10 Jan 2018 10:24:42 +0100

Hi Stephen,

Happy new year,

> bigger than some configured size (with 1500 bytes as a

I don't see zipbomb in a sense that few bits on the radio can generate a
large amount of data. Either the information is in the rule or sent. The
only way to use large amount of memory could be to send long values when a
field has a variable length, but this has an impact on the radio. I like
the sentence you are proposing to avoid this behavior.

> doesn't seem that good an idea either.
This can be a nice option for filling the rules but the draft does not go
at that level. The draft is focusing at the packet level: how to match a
field value with a target value. At this level no DNS is involved.

Laurent

Cheers,
> > As discussed during the last interim, we are starting a WGLC on the
> "LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6
> and UDP" document:
> >
> > This is a fundamental work for the WG, so please, DO review the document
> and DO provide your comments and remarks if you see any issues.
> >
> >
> >
> > In order to cover the season break, this WGLC will end in three+ weeks,
> on January 15th, 2018, 23h55 CEST, right before our next interim meeting.
> >
> >
> >
> > Best,
> >
> > Pascal and Alexander
> >
> >
> >
> >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 15 Jan 2018 17:14:40 +0000

Dear all

Please find my WGLC review below:

-         Abstract: the abstract seems a but longer than usual. The first and last paragraph seem to say most of what's needed there. Can we simplify?

"
   The SCHC header compression mechanism is independent of the specific
   LPWAN technology over which it will be used.
"

-         We could mention that there are optional/specific behaviors that may be described in technology-dependent specifications. Also, the format (eg ruleID) depends on the technology. IOW, is this document self-sufficient (seems not since we do not know the size of a rule ID).

"
   The SCHC C/D can be located on
   the Network Gateway (NGW) or in another place as long as a tunnel is
   established between the NGW and the SCHC C/D.

"

-         Maybe you can mention that the fragmentation can be decoupled and located nearer the NGW since for some LPWAN technology there may be timing constraints.

"
   Rule IDs are sent between both compression/decompression elements.

"

-         Reword?
"
   In the Dev, only the Rule-ID may be used.

"

-         You mean, I expect,  that that for a dev, "only the rule-ID is needed ".

"
  in which case the fragmentation process must be required.

"

-         Reword?

-         For APP Prefix and IID I was wondering whether we could have an equivalent to a DNS lookup  like a compute-DNS. The rule would then have a DNS name as opposed to a prefix/ IID.
"

      Nevertheless, the apropriate value will be

      defined in the corresponding technology documents.

"

-         This is the first mention of the corresponding technology documents. It should be pointed earlier (see my first comment) and non-normative references should be provided for the current ones.

"

                <------------ R ---------->
                            <--T--> <--N-->
                +-- ... --+- ...  -+- ... -+---...---+-+
                | Rule ID |  DTag  |  FCN  | payload |P|
                +-- ... --+- ...  -+- ... -+---...---+-+

"

-         P is first introduced in the image above . Is it Padding? If so please write it somewhere and explain when there is a need for it in a fragment  .

"

   <--------  R  ------->  <- byte boundary ->
               <- T -> 1 1
   +---- ... --+-... -+-+-+
   |  Rule ID  | DTag |W|1| (MIC correct)
   +---- ... --+-... -+-+-+

   +---- ... --+-... -+-+-+------- ... -------+
   |  Rule ID  | DTag |W|0|      Bitmap       | (MIC Incorrect)
   +---- ... --+-... -+-+-+------- ... -------+
                             C

"

-         Fig 10:  "C" is not aligned with the image

"
   When an All-0 fragment is received, it indicates that all the
   fragments have been sent in the current window.  Since the sender is
   not obliged to always send a full window, some fragment number not
   set in the receiver memory may not correspond to losses.  The
   receiver sends the corresponding ACK, the Inactivity Timer is set and
   the transmission of the next window by the sender can start.

"

-         Unsure I fully understand. Are you talking about the last window? A window normally starts at 2^N-2. So in a normal case yes you have a full window. But for the last one which counts down from 2^N-2 to K>0 and then has an all ones. Correct?

"
Therefore, the Hop Limit value is constant.

"

-         We can assume a constant (eg 64) going up and a different one (eg 2) going down. The value of these constants should appear in the document or in the technology docs.

Great document! I think that after some quick fixes we can request publication.

You all take care,

Pascal

From: lp-wan [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 22 décembre 2017 17:19
To: lp-wan <[email-masked]<mailto:[email-masked]>>
Subject: [lp-wan] WGLC on SCHC for IPv6 and UDP

Dear WG:

Best,

Pascal and Alexander