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.
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,
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.
(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.)
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.
draft says:
Because this document specifies that SRH is only for use within a RPL
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.
This is good, and I think the security considerations are
sufficient.
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.
However, I would be happier if the draft also recommended that by
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: ======
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list ipv6@ietf.org Administrative
Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
