Subject: [Roll] Flow Labels are wrongly used

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 10 Apr 2010 01:11:21 +0200

Flow Labels are wrongly used.

First they're wrongly represented:

>   RPL loop detection uses information that is placed into the packet in
>    the IPv6 flow label.  The IPv6 flow label is defined in [RFC2460] and
>    its operation is further specified in [RFC3697].  For the purpose of
>    RPL operations, the flow label is constructed as follows:
>
>
>         0                   1                   2
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                |O|S|R|F|  SenderRank   | RPLInstanceID |
>                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What are the first 4 bits? The diagram in rfc2460 shows 32bit wide with
the rightmost 20bits as the flow label, whereas the above diagram shows
24bit wide.

Second, the flow label MUST NOT be modified en-route by any router. Or,
RPL says:
> A router sets the 'O' bit when the packet is expect to progress down
> (using DAO routes), and resets it when forwarding towards the root of
> the DODAG iteration.   A host MUST set the bit to 0.

If the Host (a "leaf" in the tree?) sets it to 0 then 0 must stay,
intermediary Routers must not modify it, RFC3697:
> The Flow Label value set by the source MUST be delivered unchanged
> to the destination node(s).

The risk of not doing so is obvious: the communication between a Host in
the RoLL network and a host in the Internet and relying on Flow Labels
as RFC3697 - will be broken.

I like Flow Labels as Appendix A of rfc2460 I like it. It's not intended
to establish routing paths IMHO.

If one needs intermediary routers to modify stuff going through them
then better encapsulate, or at an extreme write new packets (like when
using RSVP, or when triggering route setup like Triggered RIP, or DYMO)
- but don't modify RFC2460 headers of packets not intended to self!
(other than exceptions like RH, or decrement the Hop Limit obviously).
The mutation of fields in the IPv6 headers is very dangerous breaks
things. Smiley.

Alex

---

From: Philip Levis <[email-masked]>
Date: Fri, 9 Apr 2010 17:20:50 -0700

> The mutation of fields in the IPv6 headers is very dangerous breaks

Alex,

As has been discussed many times on the list recently, the flow label approach is being replaced with a hop-by-hop header. Packets originating from within a RPL network MAY encode the instance ID within the flow label, but if they do not the instance ID will be in the proposed RPL hop-by-hop header.

Phil

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 9 Apr 2010 18:49:15 -0700

Hi Alex,

This issue was document months ago as Ticket #21.  We are working on  
moving the information into a IPv6 Hop-by-Hop Option.  A draft that  
requests and documents the RPL option was posted and presented at the  
6man WG meeting in Anaheim.

--
Jonathan Hui

On Apr 9, 2010, at 4:11 PM, Alexandru Petrescu wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 10 Apr 2010 13:11:07 +0200

Le 10/04/2010 02:20, Philip Levis a écrit :
>>> RPL loop detection uses information that is placed into the
>>> packet in the IPv6 flow label.  The IPv6 flow label is defined
>>> in [RFC2460] and its operation is further specified in
>>> [RFC3697]. For the purpose of RPL operations, the flow label is
>>> constructed as follows:
>>>
>>>
>>> 0                   1                   2 0 1 2 3 4 5 6 7 8 9 0
>>> 1 2 3 4 5 6 7 8 9 0 1 2 3
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|S|R|F|
>>> SenderRank   | RPLInstanceID |
>> What are the first 4 bits? The diagram in rfc2460 shows 32bit wide
>> with the rightmost 20bits as the flow label, whereas the above
>> diagram shows 24bit wide.
>>
>> Second, the flow label MUST NOT be modified en-route by any
>> router. Or, RPL says:
>>> A router sets the 'O' bit when the packet is expect to progress
>>> down (using DAO routes), and resets it when forwarding towards
>>> the root of the DODAG iteration.   A host MUST set the bit to 0.
>>
>>> The Flow Label value set by the source MUST be delivered
>>> unchanged to the destination node(s).
>>
>> The risk of not doing so is obvious: the communication between a
>> Host in the RoLL network and a host in the Internet and relying on
>> Flow Labels as RFC3697 - will be broken.
>>
>> I like Flow Labels as Appendix A of rfc2460 I like it. It's not
>> intended to establish routing paths IMHO.
>>
>> If one needs intermediary routers to modify stuff going through
>> them then better encapsulate, or at an extreme write new packets
>> (like when using RSVP, or when triggering route setup like
>> Triggered RIP, or DYMO) - but don't modify RFC2460 headers of
>> packets not intended to self! (other than exceptions like RH, or
>> decrement the Hop Limit obviously). The mutation of fields in the
>> IPv6 headers is very dangerous breaks things. Smiley.
>>
>
> Alex,
>
> As has been discussed many times on the list recently,

Phil - I can't seem to find that discussion.  I have archives only since
january 2010... I consider that recent enough.

> the flow label approach is being replaced with a hop-by-hop header.

The HbH (Hop-by-Hop) header can't be modified en-route either.  I hope 
Authors don't either.

> Packets originating from within a RPL network MAY encode the instance
> ID within the flow label, but if they do not the instance ID will be
> in the proposed RPL hop-by-hop header.

The important thing is to not require the intermediary RPL routers to 
modify these fields.

I am afraid one can't simply substitute the use of HbH for Flow Labels 
because the semantics described in the draft involve modifying the 
fields (e.g. the 'O' oh bit) by the routers forwarding packets, which is 
wrong.

The HbH use I know is in the Router Alert option RFC2711 and used in 
MLDv2 RFC3810.  These don't modify en route any field in the HbH.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 10 Apr 2010 13:31:40 +0200

Le 10/04/2010 03:49, Jonathan Hui a écrit :
>
> Hi Alex,
>
> This issue was document months ago as Ticket #21.

Jonathan, Ticket #21 simpy says "RPL control Bits in flow Label[...] A
decision has to be made on whether the control bits of RPL currently
specified in the Flow Label should be moved to a newly defined IPv6
extended header."

This doesn't say what the issue is.

It doesn't say HbH header.

I am not happy with this Ticket #21.

> We are working on moving the information into a IPv6 Hop-by-Hop
> Option. A draft that requests and documents the RPL option was posted
> and presented at the 6man WG meeting in Anaheim.

Ok, I read the slides and the jabber log.

Nobody seemed to ask about you modifying the HbH option en-route.  I
hope you don't, I haven't seen it elsewhere before, requires additional
per-packet processing by intermediary routers.

If your (author's) problem is to update the routing state upon arrival
of a packet which you don't have a route for then consider a use similar
to what Triggered RIP does, or similar to what DYMO and MANET
"on-demand" semantics do: hold the packet and generate new packets for
route update.

Moving encoding from Flow Label to HbH doesn't solve your fundamental
problem - which btw we haven't discussed.

The slide at
http://www.ietf.org/proceedings/10mar/slides/6man-7.pdf
says the problem is "How to manage control overhead with reactivity to
link state changes?".  The answer to that is simple: use link-state
protocols like OSPF.

slide says solution is:
> Slow proactive process - allow routing inconsistencies

Link-state protocols propagate route updates immediately upon change of
link states (hence the name) - that is as fast as it could get.

> Include routing info in data-plane packets to detect inconsistencies

No, please don't modify data-plane packets on the fly("data-plane" is
payload I believe).  Besides, if a packet arrives at a router which
doesn't know where to forward then no amount of additional data in the
packet will help find a way.

> React to inconsistencies when routes are used

This I don't understand.  Routes are always used aren't they.

Reacting to inconsistencies in the internal routing database happens
whenever a new route update is received, not when an application data is
received.  Each time a route update is received a new computation on the
table is performed and eventually send new updates.  Reacting to updates
is easy.  What's difficult is convergence time, but that doesn't depend
on the piggybacked data - it depends mostly on the number of nodes and
the number of links.

For some reason I dislike this approach of piggybacking routing
information in data packets, makes not much sense to me.  IMHO and a smiley.

Alex

> -- Jonathan Hui
>>> packet in the IPv6 flow label. The IPv6 flow label is defined in
>>>  [RFC2460] and its operation is further specified in [RFC3697].
>>> For the purpose of RPL operations, the flow label is constructed
>>>  as follows:
>>>
>>>
>>> 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
>> Second, the flow label MUST NOT be modified en-route by any router.
>> Or, RPL says:
>> _______________________________________________ Roll mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 10 Apr 2010 13:40:22 +0200

On Apr 10, 2010, at 13:11, Alexandru Petrescu wrote:

> The HbH (Hop-by-Hop) header can't be modified en-route either.

Why do you think so?

E.g., section 4.2 of RFC 2460 provides a bit for the option number to indicate one of:

      0 - Option Data does not change en-route
      1 - Option Data may change en-route

Jonathan's draft correctly sets this bit by suggesting this option value:

   HEX         act  chg  rest
   ---         ---  ---  -----
     1          00    1  01011

(See also RFC 4302 on the interaction of mutable fields with AH headers.)

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 10 Apr 2010 14:05:43 +0200

>> The HbH (Hop-by-Hop) header can't be modified en-route either.

Because I've never seen it - this is the first time.  MLDv2 employs HbH 
with immutable options.

MIPv6 uses DO headers - also immutable.

I don't understand why you want to use another header than the ICMP 
already defined in RPL.

>        1 - Option Data may change en-route

Ah!  Is there some other RFC where a HbH uses an option changed en-route?

> Jonathan's draft correctly sets this bit by suggesting this option value:

Right... AH will ignore the mutable fields.  Which means the heart of 
the RPL protocol is insecure...  should say that upfront somewhere.

Alex

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 10 Apr 2010 16:17:47 +0200

On Apr 10, 2010, at 14:05, Alexandru Petrescu wrote:

> Right... AH will ignore the mutable fields.  Which means the heart of the RPL protocol is insecure...  should say that upfront somewhere.

No, that is not at all what that means.

I cited AH to provide more evidence the fact that mutable hbh headers are part of the IPv6 architecture.

But let's talk about security.

AH, like all of IPsec, is end-to-end.
Routers are not supposed to act on it.
(Even if they wanted, they couldn't, as they are not privy to the SA governing the AH header.)

So how would an RPL hbh option interact with AH?
AH is generated at the origin of the packet and evaluated at its destination.
The RPL hbh option is inserted at the ingress of the RPL routing domain and removed (latest) at the egress.
(Obviously, if RPL needs hbh security, that will have to be added in a way that is independent of any IPsec headers present.)

Since a node outside the RPL domain cannot divine that the routing system will use RPL hbh options, it will generate/evaluate AH without the presence of that option.
The processing rules should make sure that this works correctly.

Jonathan, how about adding the following clarification to draft-hui-6man-rpl-option:

     As explained in section 1, RPL options, if present, are inserted
     inside an RPL routing domain and are removed (at least) at the
     boundaries of that domain.  Source and destination nodes of a
     packet have no control over when this happens; the presence or
     absence of the option MUST therefore be without effect on the
     security posture of the packet itself.  For example, any
     generation or evaluation of AH headers [RFC4302], if colocated
     with the addition/removal of RPL options, MUST be performed
     before the RPL option is added and after it is removed,
     respectively.  Removing an RPL option that is the only hop-by-hop
     option MUST be performed by removing the hop-by-hop option
     altogether.  [Add processing rules for when there *is* a HBH
     option already.  This could get ugly quickly because it will be
     hard to reliably restore padding if the SHOULD in section 4.2 of
     RFC 2460 "If more than one octet of padding is required, the PadN
     option, described next, should be used, rather than multiple Pad1
     options." is not heeded, or if there is more than one HBH option.]

(In other words, the RPL option is layered *under* the end-to-end delivery function of IP.  Unlike other hbh options, it is not part of the end-to-end semantics of the packet.  The fact that sticking it into the same data structure with other, possibly end-to-end hbh options, can lead to padding issues, makes Erik's comment in 6man even more interesting.)

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 10 Apr 2010 17:21:28 +0200

> The RPL hbh option is inserted at the ingress of the RPL routing domain and removed (latest) at the egress.

Carsten - what is then a Host in RPL speak (when Host MUST reset the 'O' 
oh bit)?  Is such a Host part of the RPL routing domain you mention 
above?  Or is it _outside_ this routing domain.

>       boundaries of that domain.

Carsten - I doubt any other protocol makes the intermediary routers to 
insert extension headers between the base header and the payload (of the 
originating packets).  To me it's very simple: if the dst address is not 
me then I don't touch the packet, just pass it on and decrement its Hop 
Limit.  I could create another packet by encapsulating the original 
untouched one, or remove an address from the routing header, of course. 
  I don't know of any other exception.

When inserting an additional header the overall packet Length field will 
have to change too, and then set back to the original value.  Draft-hui 
is silent about this.  I don't necessarily want it to talk about it but 
there are many aspects which need to be treated when changing packets 
enroute.

Why all this work?  Why approaching so much that NAT-like evil which 
changes packets enroute?

(YOu may know otherwise, curious about examples)

Alex

   Source and destination nodes of a

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 10 Apr 2010 09:26:41 -0700

Hi Alex,

> This doesn't say what the issue is.

It raises the question of whether we should be using the IPv6 Flow  
Label, the *exact* same question you initially raised but 4 months  
earlier.

> It doesn't say HbH header.

The HbH header is one possible solution we are pursuing at this time.

> per-packet processing by intermediary routers.

Because no one had an issue with it.  In fact, there were some  
comments indicating that this may be the best use case for a HbH  
option that they've seen.

> "on-demand" semantics do: hold the packet and generate new packets for

The problem isn't when you don't have a route - data-path validation  
doesn't work in that case because you have nowhere to send the data.   
The problem is when you have a route but the routing information is  
stale and inconsistent.  The only way to know is by exchanging  
information either in control packets or data packets.  See below why  
we prefer data packets.

> link state changes?".  The answer to that is simple: use link-state

The notion hear is to operate at the time scales of your data plane.   
The intuition is simple - if you don't use a path, why spend resources  
(energy, channel capacity, etc.) fixing it?  Wireless links change all  
the time, in many cases much faster than the rate at which you use  
them for data.

> link states (hence the name) - that is as fast as it could get.

That is exactly the behavior we do not want in LLNs.  Again, link- 
state changes often happen at much smaller time scales than the data  
plane.

> packet will help find a way.

Again, the case where no route exists is not the problem we are trying  
to solve.

> on the piggybacked data - it depends mostly on the number of nodes and

It depends on how often you exchange routing information.  Again, you  
want that to happen on data-plane time scales.

> information in data packets, makes not much sense to me.  IMHO and a  

This mechanism has been in the draft since 04.  It was presented in  
Hiroshima.  You are the first to have a serious objection.

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 10 Apr 2010 09:45:10 -0700

Hi Carsten,

On Apr 10, 2010, at 7:17 AM, Carsten Bormann wrote:

> The RPL hbh option is inserted at the ingress of the RPL routing  
> domain and removed (latest) at the egress.
> (Obviously, if RPL needs hbh security, that will have to be added in  
> a way that is independent of any IPsec headers present.)
>
> Since a node outside the RPL domain cannot divine that the routing  
> system will use RPL hbh options, it will generate/evaluate AH  
> without the presence of that option.

Thanks, Carsten.  This is a good clarification to bring out.

> (In other words, the RPL option is layered *under* the end-to-end  
> delivery function of IP.  Unlike other hbh options, it is not part  
> of the end-to-end semantics of the packet.  The fact that sticking  
> it into the same data structure with other, possibly end-to-end hbh  
> options, can lead to padding issues, makes Erik's comment in 6man  
> even more interesting.)

One possibility to maintain alignment is to require the RPL option to  
be sized such that it maintains the alignment of any existing options  
(e.g. require a size of always 6+8n if inserting at the beginning or  
simply 8n if inserting at the end).  We could also be conservative  
with the PadN vs. Pad1 issue by saying that all existing options  
(including PadN and Pad1) cannot be removed when inserting a RPL  
option.  Of course, this assumes that options will never need to be  
aligned on larger boundaries (e.g. 16n), but is there a case for that?

--
Jonathan Hui

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 10 Apr 2010 21:50:20 +0200

Hi Jonathan,

Le 10/04/2010 18:26, Jonathan Hui a écrit :
>> Jonathan, Ticket #21 simpy says "RPL control Bits in flow
>> Label[...] A decision has to be made on whether the control bits
>> of RPL currently specified in the Flow Label should be moved to a
>> newly defined IPv6 extended header."
>>
>>> Option. A draft that requests and documents the RPL option was
>>> posted and presented at the 6man WG meeting in Anaheim.
>>
>> hope you don't, I haven't seen it elsewhere before, requires
>> additional per-packet processing by intermediary routers.
>
>> If your (author's) problem is to update the routing state upon
>> arrival of a packet which you don't have a route for then consider
>> a use similar to what Triggered RIP does, or similar to what DYMO
>> and MANET "on-demand" semantics do: hold the packet and generate
>> new packets for route update.
>
>> Moving encoding from Flow Label to HbH doesn't solve your
>> fundamental problem - which btw we haven't discussed.
>>
>> The slide at
>> http://www.ietf.org/proceedings/10mar/slides/6man-7.pdf says the
>> problem is "How to manage control overhead with reactivity to link
>> state changes?". The answer to that is simple: use link-state
>> protocols like OSPF.
>
> The intuition is simple - if you don't use a path, why spend
> resources (energy, channel capacity, etc.) fixing it? Wireless links
> change all the time, in many cases much faster than the rate at which
> you use them for data.
>
>> slide says solution is:
>> Link-state protocols propagate route updates immediately upon
>> change of link states (hence the name) - that is as fast as it
>> could get.
>
> That is exactly the behavior we do not want in LLNs. Again,
> link-state changes often happen at much smaller time scales than the
> data plane.

Hmm... interesting to hear that.  Do we have some quantification or
example of this statement - what does it look like?  What application is
used?  Periodic querying of sensor data - which app protocol?  What link
layer is used which is so often unstable?  Any thoughts along this line.

This qualifying of links going down more often than data being sent
(smaller time scales) makes think one needs to send heartbeat control
packets right before sending data packets.

>> No, please don't modify data-plane packets on the fly("data-plane"
>> is payload I believe). Besides, if a packet arrives at a router
>> which doesn't know where to forward then no amount of additional
>> data in the packet will help find a way.
>
> Again, the case where no route exists is not the problem we are
> trying to solve.

But absence of route is equivalent to a route being stale or incosistent.

>> Reacting to inconsistencies in the internal routing database
>> happens whenever a new route update is received, not when an
>> application data is received. Each time a route update is received
>> a new computation on the table is performed and eventually send new
>> updates. Reacting to updates is easy. What's difficult is
>> convergence time, but that doesn't depend on the piggybacked data
>> - it depends mostly on the number of nodes and the number of
>> links.
>

You may want it on a certain time-scale - ok.  How about the Host (leaf,
end-node, Client) sending heartbeat control packets right before sending
its data, just to make sure a path exists.

> Hiroshima. You are the first to have a serious objection.

Well thanks for making me a first... I believe these things
(paging for power-save, piggybacking, heartbeats, on-demand, triggering,
data vs control) have been discussed many times on other protocols.

Heartbeat could be Router Alert (Option Data does not change en-route).
  MLDv2 uses it piggybacked on data packets.  RPL Host could piggyback it
in the same way.  But I see that as an optimization.  One can't request
every app on RPL node to piggyback it.

Better have first the RPL control (ICMP) first separated completely from
data packets.  And see later for HbH optimization.

I would like to make sure that any application works ok unmodified on a
Host in the RPL network (e.g. httpd), and not only those which
piggyback, or which send control packets before sending their data.

Not sure how to explain but really deserves discussion.  Should have 
been in requirements actually... don't modify apps, don't change packets 
enroute, talk to Internet nodes, etc.

Alex

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Apr 2010 20:39:13 -0400

>>>>> "Carsten" == Carsten Bormann <[email-masked]> writes:
    Carsten> On Apr 10, 2010, at 14:05, Alexandru Petrescu wrote:

    >> Right... AH will ignore the mutable fields.  Which means the
    >> heart of the RPL protocol is insecure...  should say that upfront
    >> somewhere. 

    Carsten> No, that is not at all what that means.

    Carsten> I cited AH to provide more evidence the fact that mutable
    Carsten> hbh headers are part of the IPv6 architecture. 

    Carsten> But let's talk about security.

    Carsten> AH, like all of IPsec, is end-to-end.
    Carsten> Routers are not supposed to act on it.
    Carsten> (Even if they wanted, they couldn't, as they are not privy
    Carsten> to the SA governing the AH header.) 

Well, that's a key distribution problem.
There is nothing fundamental about AH that prevents this.

The issues with AH that prevents SEND from using it were really an
oversight in the 2401 specification --- the SEND security would not have
been ignored by insecure nodes, rather than entire packet would have
been dropped.  Too late to revise deployed nodes.
RPL does not have this problem, in my opinion.

AH is a useful construct for layer-3 security, and it may be available
in hardware (almost for free) in many embedded environments. (ixp and
freescale come to mind)

They key distribution problem is a problem that any layer-3 solution
will need to solve.

Carsten talks about who creates AH and who processes it --- in most
cases the DIOs and DODAGs are unicast, or multicast (therefore, "for"
all nodes).  Multicast AH is well understood.

(IPsec guy)

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Apr 2010 09:07:21 +0200

> all nodes).  Multicast AH is well understood.

Actually, I was considering the case where a *data* packet is being forwarded and the routers on the way insert routing information into an IPv6 hop-by-hop option, further modify that on the way and (to make AH work) finally remove all this stuff again before handing it to the destination process.  Any AH in there is protecting the end-to-end information; there is no way that same protection can be used to protect information that is inserted/modified hop-by-hop.  No, I'm not giving the end-to-end keys to every router on the way :-)

(I agree that AH could be used to secure RPL-specific packets sent between routers; I'm not so sure this is a good match.)

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 13 Apr 2010 12:30:50 +0200

Le 13/04/2010 09:07, Carsten Bormann a écrit :
>> cases the DIOs and DODAGs are unicast, or multicast (therefore,
>> "for" all nodes).  Multicast AH is well understood.
>
> Actually, I was considering the case where a *data* packet is being
> forwarded and the routers on the way insert routing information into
> an IPv6 hop-by-hop option, further modify that on the way and (to
> make AH work) finally remove all this stuff again before handing it
> to the destination process.

This can't work when the src and dst of the application data are both
Routers within the RPL domain:

       R1---R2---R3 as opposed to

  H1---R1---R2---R3---H2 which could work.

Or are you going to restrict Routers from running applications?

Alex

   Any AH in there is protecting the
> end-to-end information; there is no way that same protection can be
> used to protect information that is inserted/modified hop-by-hop. No,
> I'm not giving the end-to-end keys to every router on the way :-)
>
> (I agree that AH could be used to secure RPL-specific packets sent
> between routers; I'm not so sure this is a good match.)
>
> Gruesse, Carsten
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Apr 2010 19:26:06 +0200

Following up on my own post...

I just found out about the 6MAN WG proposal to have mutable Flow 
Labels... maybe that will fly maybe that will not.  It's too early to 
decide and rely RPL on it?  I think?

(also I found Flow Labels aren't typically covered by AH, I stand
  corrected on this - but it makes insecure the overall idea of using
  the Flow Labels at the heart of RPL - be them mutable or not).

Alex

Le 13/04/2010 12:30, Alexandru Petrescu a écrit :
>>> Carsten talks about who creates AH and who processes it --- in
>>> most cases the DIOs and DODAGs are unicast, or multicast
>>> (therefore, "for" all nodes). Multicast AH is well understood.
>>
>> Actually, I was considering the case where a *data* packet is
>> being forwarded and the routers on the way insert routing
>> information into an IPv6 hop-by-hop option, further modify that on
>> the way and (to make AH work) finally remove all this stuff again
>> before handing it to the destination process.
>
> This can't work when the src and dst of the application data are
> both Routers within the RPL domain:
>
>> end-to-end information; there is no way that same protection can
>> be used to protect information that is inserted/modified
>> hop-by-hop. No, I'm not giving the end-to-end keys to every router
>> on the way :-)
>>