Re: AH over RH new type of RPL (was: Comment on rpl-routing-header draft)

[Alexandru Petrescu <[e-mail]>]

Hello Jonathan, Jari, IPv6 WG,

Please allow me to take advantage of this discussion to mention security 
of this new type of routing header.

RFC 4302 "AH" knows RHs but not this new type of RH.

It may be valuable to have an appendix which shows an example of how the 
AH over this routing header works, in a step-by-step manner:

(currently, the draft does say algorithm to process RH but does not say
  how it should be recomputed at receiver to be re-covered by AH for
  checking).

> 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 |

References:
RFC 4302 "AH" knows RHs but not this new type of RH.

Discussion, email credit Robert Cragie
http://www.ietf.org/mail-archive/web/ipv6/current/msg13769.html
April 2nd, 2011

http://www.ietf.org/mail-archive/web/roll/current/msg05418.html
September 10th, 2010

> Hi Jari,
>
> Thanks for the review.  As you did below, I too need to apologize for
> the delay in responding.  See my responses below:
>
> On Jun 10, 2011, at 3:46 PM, Jari Arkko wrote:
>
>> I have reviewed this draft.
>>
>> I have a number of comments, most of which are at this point
>> questions and discussion items. The comments are included below in
>> three categories: technical comments, editorial comments, and
>> comments relating to feedback from other people that may not been
>> fully handled yet. In general, the draft is well written and
>> largely ready to move to a Proposed Standard RFC. However, there
>> are a couple of issues that we need to discuss: MTU requirements,
>> recommendations to consider alternative designs that exist only as
>> Internet Drafts, and the feasibility of the loop check.
>>
>> I also need to apologize that it has taken far too long for me to
>> do this review. There's no good excuse, but I've had some number of
>> other documents in the queue this spring, day job requirements, and
>> I knew I needed to review this document carefully. The rpl-option
>> draft is next on my reading queue, probably reviewed by Monday.
>>
>> Technical: =======
>>
>>> links within a RPL domain SHOULD have a MTU of at least 1280 + 40
>>> (outer IP header) + SRH_MAX_SIZE (+ additional extension headers
>>> or options needed within RPL domain) octets.
>>>
>>
>> I thought that 6LOWPAN was an important link layer for the
>> application of RPL. Yet, RFC 4944 specifies a MTU of 1280 octets.
>> The above requirement seems to be in contradiction with what is
>> available on 6LOWPAN. Am I missing some extension of 6LOWPAN that
>> changes the MTU, or some other link layer that is expected to be
>> used with RPL? If I'm not missing anything, wouldn't this cause a
>> problem? It would seem that either you cannot run RPL on 6LOWPAN,
>> run 6LOWPAN on non standard MTU values (and we know MTU negotiation
>> is difficult), or you have to change the expectations of other
>> nodes in the IPv6 Internet about the minimum assured MTU.
>>
>> Please clarify/resolve/tell me what I am missing.
>
> Yes, 6LoWPAN is one of the target link layers.  I agree that this
> statement is problematic with strict adherence to RFC 4944.  Note,
> however, that there are IEEE 802.15.4 variants (i.e. 802.15.4g) that
> support frame lengths up to 2KB.  I'm not sure it would be wise to
> limit the capabilities of alternative IEEE 802.15.4 link
> technologies.
>
> I would propose to remove the cited statement.  It is unnecessary
> given that the next revision of this draft will require tunneling.
>
>>> A common network configuration for a RPL domain is that all
>>> nodes within a LLN share a common prefix.  The SRH introduces the
>>> CmprI, CmprE, and Pad fields to allow compaction of the
>>> Address[1..n] vector when all entries share the same prefix as
>>> the IPv6 Destination Address field of the packet carrying the
>>> SRH.
>>
>> So all segments are treated based on how many bytes they have in
>> common with the destination address. But the destination address
>> keeps changing as we go through the intermediate hops. Is it
>> necessary to clarify that the comparison/shared prefix is with the
>> final destination address, NOT the address that happens to be in
>> the destination address field currently?
>
> The intent really was to utilize the current IPv6 Destination value
> since all entries except the last will carry the same CmprI prefix
> bytes.  Now, I can see there is an issue when we consider the final
> entry controlled by CmprE.  The intent was that CmprE would only
> differ when operating in "transport mode" and the SRH would thus be
> removed according to Section 5 of the draft.
>
>>> In very specific cases, IPv6-in-IPv6 tunneling may be undesirable
>>> due to the added cost and complexity required to process and
>>> carry a datagram with two IPv6 headers.
>>> [I-D.hui-6man-rpl-headers
>>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-routing-header-03#ref-I-D.hui-6man-rpl-headers>]
>>> describes how to avoid using IPv6-in-IPv6 tunneling in such
>>> specific cases and the risks involved.
>>>
>>
>> This sounds like a recommendation to do something in a draft that
>> has not been through the working group and approved as the
>> something that is a sound practice. Unless the reference is
>> normative, I think it is inappropriate to refer to an Internet
>> draft in this manner.
>>
>> What I would recommend is to (1) change the "... SHOULD use
>> IPv6-in-IPv6 tunneling ..." statement to a MUST in this draft, (2)
>> remove the above text, and (3) make the corresponding changes to
>> Section 5. Then we can take hui-6man-rpl-headers through the
>> working group and provide a second, more light-weight approach that
>> extends what we have RFC-to-be-draft-ietf-6man-rpl-routing-header.
>>
>> (FWIW, I think the problem begins when one adds the first byte to a
>> packet somewhere along the route. It does not not matter so much
>> how many bytes one adds, just the SRH or also the IP header. Most
>> of the complications on MTUs and so one start at that point. In any
>> case, SRHs may not be trivially small either. Assuming 64-bit
>> prefix compression an SRH for 4 hops would be 40 bytes.)
>
> In general, I agree with your concern.  However, after re-reading the
> draft, do is it necessary to mandate a particular solution (i.e. RFC
> 2473)?  Instead, how do you feel about the following modified text:
>
> To deliver a datagram, a router MAY specify a source route to reach
> the destination using a SRH.  There are two cases that determine how
> to include an SRH with a datagram.
>
> 1.  When the source node inserts an SRH, it may do so directly within
> the datagram itself.
>
> 2.  When an intermediate node inserts an SRH, it should do so in a
> way that does not cause path MTU issues and ensures ICMP errors
> caused by inserting the SRH return to the source of the SRH rather
> than the original datagram.  One such method is IPv6-in-IPv6
> tunneling [RFC 2473].
>
>>> If such addresses appear more than once and are separated by at
>>> least one address not assigned to that router, the router MUST
>>> drop the packet and SHOULD send an ICMP Parameter Problem, Code
>>> 0, to the Source Address.
>>>
>> ...
>>
>>> else if 2 or more entries in Address[1..n] are assigned to local
>>> interface and are separated by at least one address not assigned
>>> to local interface { discard the packet }
>>>
>>
>> The text and the code appear to disagree about whether to send an
>> ICMP Parameter Problem message. Please align. I assume that an ICMP
>> message is needed.
>
> Agree.
>
>>> Because this document specifies that SRH is only for use within a
>>> RPL domain, such attacks cannot be mounted from outside the RPL
>>> domain. As described in Section 5
>>> <http://tools.ietf.org/html/draft-ietf-6man-rpl-routing-header-03#section-5>,
>>> RPL Border Routers MUST drop datagrams entering or exiting the
>>> RPL domain that contain a SRH in the IPv6 Extension headers.
>>>
>>
>> This is good, and I think the security considerations are
>> sufficient. However, I would be happier if the draft also
>> recommended that by default, non-RPL routers and firewalls should
>> drop packets with SRH. This would help ensure that SRH does not
>> accidentally enter any network and expose some vulnerability. The
>> practical effect that I'm looking for is, for instance, not having
>> my Linux kernel process SRH unless I've configured it to use RPL.
>
> Agree.
>
>> Editorial: ======
>>
>>> In the above scenario, datagrams traveling from source, S, to
>>> destination, D, have the following packet structure:
>>>
>>>
>>> +------+------+------+--------//-+ | IPv6 | IPv6 | IPv6 | Packet
>>> | | Src  | Dst  | SRH  | Payload   |
>>> +------+------+------+--------//-+
>>>
>>
>> This figure is not as clear as it could be. Are the src and dst
>> field referring to the IPv6 header fields? Would this picture be
>> better if you showed the IPv6 header explicitly? Please clarify.
>
> Yes, the src and dst fields are IPv6 header fields.  Will update the
> figure to be more explicit.
>
>>> CmprE             4-bit unsigned integer.  Number of prefix
>>> octets from the segment that are elided.  For example, a SRH
>>> carrying a full IPv6 address in Addresses[n] sets CmprE to 0.
>>>
>>
>> I understood the definition CmprI, but I do not understand this, at
>> least not at the point of the above text. What is "the segment"
>> that you are referring to above? SRH carries multiple segments.
>> Please clarify.
>>
>> Little further down it becomes clear that CmprE refers to the
>> compression of the last segment. Please make this clear already in
>> the above text.
>
> Correct.  Will clarify in the next revision.
>
>> Comments relating to feedback from others:
>> ============================
>>
>> The ADs have received a question from Joseph Reddy, who was asking
>> if the set of addresses in the SRH should also include the source
>> address of the node inserting the SRH. His justification for this
>> was the need to be able to send an ICMP error back to this node. Do
>> we have an answer?
>
> When using tunneling, the ICMP error should go back to the source of
> the outer IPv6 header.
>
>> In April, Thomas Narten made some comments on the list and I didn't
>> think that the discussion finished with any conclusion. Are his
>> concerns (e.g., from his e-mail on April 29th) valid or not valid?
>> I would like the working group to conclude this issue one way or
>> the other. I refer to his comments regarding the feasibility of the
>> loop check in particular. His e-mail is at
>> http://www.ietf.org/mail-archive/web/ipv6/current/msg13887.html
>> FWIW I agree with Thomas' editorial comment on Section 2 clarity.
>> That should be easy to fix.
>
>
> My personal belief is that LLN devices will generally have more
> computation capability relative to communication capability, so I'm
> not terribly concerned with the processing overhead.  That said, I'm
> not a fan of the loop check and would prefer less complexity.  We
> only required such checks to deal with security concerns that have
> been raised in the past with RH0.  If others feel that the checks are
> unnecessary or have alternative suggestions, I'm more than happy to
> make the changes.
>
> Thanks.
>
> -- Jonathan Hui