Subject: AD review of draft-ietf-6man-rpl-routing-header

From: Jari Arkko <[email-masked]>
Date: Sat, 11 Jun 2011 01:46:02 +0300

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.

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

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

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

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

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.

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

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?

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.

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 16 Jun 2011 16:12:20 +0200

IPv6 6MAN WG,

I take advantage of this AD message to post comments about this draft.

Le 11/06/2011 00:46, Jari Arkko a écrit :
[...]
>> 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.
>
> 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
> What I would recommend is to (1) change the "... SHOULD use
> IPv6-in-IPv6 tunneling ..." statement to a MUST in this draft,

I can say that I agree with the direction of using IPv6-in-IPv6
tunnelling in this context, and avoid the use of RH.

But even then, I think there still some things unclear about the use of
IPv6-in-IPv6 in the draft.  (for example it makes no sense to
encapsulate when both S and D are under same BR, figure on Page 6,
despite text saying "datagrams travel from S to D through BR1. [...] BR1
encapsulates received datagrams unmodified using IPv6-in-IPv6 and [...]").

Second, intuitively, using IP encapsulation on BR in order to connect BR
and the RPL network to the Internet dangerously approaches to a number
of existing methods of achieving same: Mobile IP, or a pure tunnel
broker, etc.  These methods should be reused, otherwise I need to
understand why designing new methods.

Third, there is a very strong lack of architectural perspective here
about BRs, tunnels and the rest of Internet nodes.  There is no
suggestion about who are the RPL nodes (below BR) talking to?  If we
assume that  the BR does IP-in-IP encapsulation, then is it still
possible that nodes below BR still can talk to any other node in the
Internet?  Do we need to modify these nodes to support IP-in-IP
encapsulation when talking to nodes below BR?

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

This makes sense to me.  I support this approach as long as it implies
more clarification on the IP-in-IP encapsulation as well.

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

I agree with a thing above: modifying packets on-route has strong
consequences on some things such as MTU and, additionally, on the
assumed security mechanism be it IPsec.  IPsec is not specified to work
with any other routing header than what exists already.

> domain, such attacks cannot be mounted from outside the RPL domain.

Ok, how about attacks mounted from _inside_ the RPL domain?  Do you
think they can't exist?  Thus, do you agree that any this draft's RH is
fully insecure?

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

No, I don't think so (sorry).

A new RH type is not understood by existing IPsec, hence unprotected.
Besides, the Security Section seems to assume there can be no attack
from within the RPL network to another node within that same network.  I
think this perspective is not good.

> default, non-RPL routers and firewalls should drop packets with SRH.

I could agree to this but... hmmm, it is so disapointing when packets
can't travel from everywhere to everywhere else because being dropped by
an entry in a table-driven non-protocol filter.

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

Makes sense to me.

Alex

> Editorial: ======
>> +------+------+------+--------//-+ | IPv6 | IPv6 | IPv6 | Packet |
>> | Src | Dst | SRH | Payload | +------+------+------+--------//-+
>
> referring to the IPv6 header fields? Would this picture be better if
> you showed the IPv6 header explicitly? Please clarify.
>
>
>> 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.
>
> 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.
>
> compression of the last segment. Please make this clear already in
> the above text.
>
> 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?
>
> 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.
>
> Jari
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>