Hi Alex,

Thank you for focusing on a pertinent issue. You are right to highlight 
what we do with a RH4 header as I believe secured DAO ACK is the (only) 
RPL control message which requires RH4 in non-storing mode.

So, to follow the rules for mutable and predictable fields (see RFC 
4302), we can resubstitute at the end:

Consider the following:

A -> B -> C -> D -> E

A -> B:

|Src|Dst|RH4            |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
| A | B | 3 | C | D | E |

B -> C:

|Src|Dst|RH4            |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
| A | C | 2 | B | D | E |

C -> D:

|Src|Dst|RH4            |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
| A | D | 1 | B | C | E |

D -> E:

|Src|Dst|RH4            |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
| A | E | 0 | B | C | D |

When the packet arrives at E, recreate the original RH4 header for MAC 
computation:

n = ((Hdr Ext Len * 8) - Pad) / (16 - Comp)
tmp = Dst
Dst = RH4.A[0]
RH4.Seq = n
for (k = 1; k < n; k++)
{
   RH4.A[k-1] = RH4.A[k]
}
RH4.A[k] = tmp

|Src|Dst|RH4            |
|   |   |Seq|L0 |L1 |L2 |
-------------------------
| A | B | 3 | C | D | E |

Is that acceptable?

Now, just because I refer to IPSec AH, it doesn't mean I am suggesting 
we use it. I am suggesting we can use the fundamental principles from 
IPSec for an equivalent operation.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>


On 10/09/2010 4:22 PM, Alexandru Petrescu wrote:
> Le 10/09/2010 11:55, Robert Cragie a écrit :
>> David,
>>
>> I totally agree with what you say. Thank you for restating generally
>>  that IPSec has already been extensively considered - I use the term
>>  'paraphernalia' as a general term for the overheads.
>>
>> Alex - can we please drop the IPSec discussion and move on and
>> concentrate on the things which do need to sorted out?
>
> Ok... let me try to avoid dissent and do what you ask.
>
> Let's come back to RPL-11 text:
>> 3.  If the packet header specifies a source route by including a RH4
>> header as specified in [I-D.ietf-6man-rpl-routing-header]
>
> then draft-ietf-6man-rpl-routing-header-00 says:
>> else { swap the IPv6 Destination Address and Address[i]
>
> That means that there is a mutable but predictable field (IPv6
> Destination Addess) in RH of RPL.  But RPL Security doesn't understand
> mutable but predictable fields (only mutable as per recent discussion).
>  RPL Security covers "entire IPv6 packet", which changes enroute despite
> RPL Security's expectation it won't change.
>
> So the question is: does RPL Security secure the RH4 header?  I think it
> does not, because its MAC computation does not say how are the mutable
> but predictable fields covered.
>
> For example, a sender builds a packet with Dst address1, computes MAC,
> inserts MAC.  Then intermediary routers process that packet and replace
> that Dst address1 with address2 from the Routing Header.  Now the packet
> is received at address1.  The MAC can't be meaningfully computed on the
> receiver, because the "IPv6 entire packet" has changed, it is not the
> same as at emission.
>
> I think this example is correct.
>
> It can't be solved in the same way we solved the mutability of "Hop
> Limit" (we said to make HopLimit set to 0 for MAC calculation), because
> if we do so then we have a higher risk of attack than when left HopLimit
> unsecure.  If we set to 0 de Dst for MAC calculation then the risk of
> implication of forged IP dst addresses is higher than forged HopLimit.
> Forging an IP dst address is stronger security attack than forging
> HopLimit, intuitively speaking.
>
> Besides, whereas the receiver has really no idea about what could the
> original HopLimit be, it knows precisely what the original Dst address
> was (it's in the RH4, swapped).  Thus the securing solution should be
> different - it should be as smart as RH4 is.
>
> Knowing the previous discussion, it may be possible that people will
> request we refer to that Authentication Header RFC which tells how
> mutable, mutable but predictable fields are dealt with.  At that point
> we come back to IPsec, but I will abstain from saying so if you wish.
> There is also the fact that previous IPsec talk says RH0 whereas here we
> have RH4 and things may be different.
>
> That's too long for anyone to read, but you get the point.
>
> Alex
>
>
>
>
>  You are of course
>> entitled to your opinion but progress is only made in the IETF
>> through rough consensus. Consensus does not mean unanimous agreement;
>> if we can all at least consent to a solution then the process will
>> run a lot more smoothly and we will all benefit. Continual dissent
>> will only serve to hinder this progress.
>>
>> I think the consensus is clear:
>>
>> * We do not mention IPSec in RPL security * The mutable field
>> discussion is entirely independent from IPSec
>>
>> Robert
>>
>> Robert Cragie (Pacific Gas & Electric)
>>
>> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44
>> 1924 910888 +1 415 513 0064 http://www.gridmerge.com
>> <http://www.gridmerge.com/>
>>
>>
>> On 09/09/2010 9:33 PM, David Culler wrote:
>>> Dear Alex, Thank you for focusing on the question of routing
>>> security, rather than internet security in general.  Yes, IPSec has
>>> been utilized to secure routing protocols.  Now please take the
>>> next step and focus on routing for low power and lossy networks.
>>> Obviously, IPSec has to be the first thing considered.  And it was.
>>> Dating back to the earliest security framework discussions it was
>>> considered many times.   We returned to the IPSec issue extensively
>>> back in June on the mailing list.   I won't reiterate the
>>> discussion on the storage and time complexity, nor the message
>>> overhead implications that were in those prior postings.  But I
>>> will observe that no one suggested that they saw their way to a
>>> full IPSec implementation within the constraints articulated in the
>>> Routing Requirements documents.   The WG group has long since
>>> reached a rough consensus on this matter and moved on.  That is the
>>> nature of a group process and specifically the role of WG LC.  At
>>> some point, we commit to certain things and stop revisiting them
>>> from first principles.   That allows us to focus more sharply on
>>> the selected approach and refine it more completely.  For example,
>>> in security, we have specifics to resolve, such as which header
>>> fields need to be skipped.  It is not a matter of "but I imagine
>>> that there may be alternatives".  There might be.  But we don't
>>> just turn the same rocks over and over again.  We carve the rough
>>> stone, we chisel the details, we sand, we polish.
>>>
>>> So I assume that the point of your posting is that you want to be
>>> sure that the justification for the choices that the WG made are
>>> properly documented in the WG documents.  If you feel that they are
>>> not, perhaps you could point to the document and section that you
>>> feel should contain this material more substantially.
>>>
>>> D.
>>>
>>> For reference,http://www.ietf.org/tao.html  section 7.4
>>>
>>>
>>> On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote:
>>>
>>>> Le 09/09/2010 16:59, David Culler aécrit :
>>>>> The RPL charter calls for us to address routing security
>>>>> considerations.  Not security in general.  Not application
>>>>> security. Not link level.  Routing security.  It is focused for
>>>>> good reason.
>>>> Routing security like OSPF using IPsec? "Authentication has been
>>>> removed from the OSPF protocol and instead relies on IPv6's
>>>> Authentication Header and Encapsulating Security Payload (ESP)."
>>>> says rfc5340... why does RPL need to be different in this
>>>> respect?
>>>>
>>>> Alex
>>>>
>>>>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote:
>>>>>
>>>>>> Le 08/09/2010 18:15, Philip Levis aécrit :
>>>>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote:
>>>>>>>
>>>>>>>> Le 03/09/2010 13:48, Robert Cragie aécrit : [skipped
>>>>>>>> agreed opinions about IPsec]
>>>>>>>>>> Reusing the IPsec module ensures a secure system -
>>>>>>>>>> it's proven by earlier experience. We know it worked
>>>>>>>>>> ok so why avoid using it.
>>>>>>>>> <RCC>I don't think the specification of RPL security
>>>>>>>>> precludes the use of IPSec instead. Does the use of
>>>>>>>>> IPSec need to be specified in the RPL
>>>>>>>>> specification?</RCC>
>>>>>>>> YEs, the RPL specification must say something about
>>>>>>>> security in its Security Considerations section.  That
>>>>>>>> something has to mention something about IPsec.
>>>>>>> Why does it have to do so? In theory, RPL should be
>>>>>>> entirely independent of IPSec. There have already been
>>>>>>> numerous discussions about why simply relying on IPSec
>>>>>>> would be problematic. Unfortunately you seem to forget
>>>>>>> these points every few weeks and rehash the same
>>>>>>> discussion. At some point it becomes a waste of everyone's
>>>>>>> time.
>>>>>> Phil - if RPL says "security" then it must understand that
>>>>>> Internet security is usually IPsec.  This is truer with IPv6
>>>>>> (as opposed to IPv4) where IPsec is very much integrated in
>>>>>> the design (mutable fields, etc.)
>>>>>>
>>>>>> Have you checked the mutable field discussion?  Do you agree
>>>>>> that mutable fields must be taken into account?
>>>>>>
>>>>>> Please read that around 3 people agreed on a list of items
>>>>>> which are worth discussion of security and IPsec - mutable
>>>>>> fields is one such item.
>>>>>>
>>>>>> As such this discussion is not a waste of everyone's time.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>> Phil
>>>>>>
>>>>>> _______________________________________________ Roll mailing
>>>>>> list Roll@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/roll
>>>>> David Cullerculler@cs.berkeley.edu  Chair Computer Science
>>>>> Associate Chair EECS
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>> David Culler culler@cs.berkeley.edu Chair Computer Science
>>> Associate Chair EECS
>>>
>>>
>>>
>>> _______________________________________________ Roll mailing list
>>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>>>
>>
>>
>> _______________________________________________ Roll mailing list
>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>