[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on multi6dt documents
Hi,
I read the 5-document set of multi6dt documents. In general, I
thought they were a very useful start, but there were some
inconsistancies across documents, and clearly there was not yet time
to analyze how the solution (or different pieces of solution)
correspond to the "thinks-to-think-about" document.
This especially seemed to be the case with the shim layer document,
which might end up having some potentially significant issues.
===============================
HBA:
substantial
-----------
I think there are two big issues:
1) The spec should have a clear section which describes the assumptions
placed upon the features which must be supported in the multi6 solution. In
this particular case, for example, the CGA Parameter Data Structure needs to
be passed to the peers out of band because otherwise they can't perform
verification. This might help in figuring out how the HBA address
generation integrates to the rest of the multi6 solution problem space.
2) IPR. Unfortunately, SEND had IPR; fortunately, RF licensing was granted
for implementations of SEND. Someone has to figure out how generic those
patent applications were, i.e., whether HBA would be covered as well.
editorial
---------
5. HBA verification
==> I spotted about 3 typos in this section, and one helluva long paragraph
which should be split up.
==================================
Referrals:
substantial
-----------
- "Identity" comparison. Some applications might retain the IP
address, not as a means to initiate communication as in the above
cases, but as a means to compare whether a peer is the same as
another peer. While this is insecure in general, it might be
something which is used e.g., when TLS is used.
==> I think the document should use a bit of space to discuss (or refer
to) why identity comparison is insecure in general. This seems to be true
in the sense that if you have an established secure application identity,
and you come across a new identity which uses the same IP address in an
insecured manner, then comparing them might not be sufficient (example:
IPsec-secured w/ IP=1.1.1.1 session being tampered by a packet with source
address of IP=1.1.1.1). But if the security levels of comparison are equal,
I don't think there is a real problem.
- Even if the bullet above is addressed somehow, the introduction of
RFC 3041 temporary addresses for improved privacy adds to the
burden. Today there is no mechanism for a host with temporary
addresses to create temporary FQDNs that resolve to those
addresses, and temporary FQDNs are necessary to preserve the
difficulty of correlating these addresses with more permanent
identifiers of the host.
==> this may or may not be true. RFC3041 even mentions DNS names based on
RFC3041, as long as they are not identifying the real user, and
draft-ietf-dnsop-ipv6-issues-10.txt discusses this a bit as well.
I think the more appropriate formulation is that mechanisms do exist, but
the hosts do not implement these automatically (an implementation issue),
and even if they did, the DNS zone admins might not allow the required DNS
updates.
Unique local addresses could be treated following approach as just
another locator which is known to be unreachable (at least when
outside the site to which it is assigned), thus there might be some
performance optimizations that can be applied. But the fact that the
identifier is centrally assigned means that it is reasonable to
==> this draft makes the assumption that there would be only centrally
allocated ULAs, which is not correct. There will definitely be other ULAs,
but those would likely have no chance to be used in these kinds of mappings
because there's chance this kind of mapping could be established. But
that's quite different from this silent assumption.
editorial
---------
and for a given transport connection a pair
consisting of a local and a peer locator are chosen as part of the
identification of the connection.
==> s/a pair/, a pair/
==> s/are//
However, it is far from clear that this is feasible for all
applications in all deployments. Reasons why FQDNs are problematic
include
==> s/include/include:/
In this case it is possible to perform a reverse lookup of the single
IP address to find out the FQDN, followed by a forward lookup of the
FQDN to find all the AAAA records. This method finds all the
locators registered in the DNS but assumes that both the reverse tree
and the forward tree are maintained.
==> s/maintained/maintained in a consistent manner/ -- or the like: it's not
sufficient to just put some stuff in the reverses or forward trees, they
must be actively kept in sync. This is an area which is not often the
case..
==> s/likely/likely to/
[NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the
NSRG", draft-irtf-nsrg-report-09.txt (work in progress),
March 2003.
==> wasn't this an RFC already?
[HIP] Pekka Nikander, "Considerations on HIP based IPv6 multi-
homing", 23-Jan-04, <draft-nikander-multi6-hip-00.txt>
==> I thought this became a HIP wg item?
==================================
Failure detection:
substantial
-----------
Generic observation: I found section 2 extremly illustrative and useful --
I was surprised there has been a vast amount of work by different parties on
this. It would seem to be natural to consider whether creating a mailing
list for discussion of this particular topic would be a good idea; this
touches on multi6, sctp, mobike, hip, and also application peoples'
expectations about the robustness of mechanisms to detect network problems
(for example, currently the mechanisms to recover from blackholed traffic
are very poor, and this could help with non-multihomed case as well).
Obviously, this could also lead to a trying to solve every problem
(except maybe world hunger) and getting nothing done in the end, but I
guess it might be useful to have some more united forum to discuss these
issues rather than crossposting to about 5 different mailing lists :-)
semi-editorial
--------------
SCTP does not define how local knowledge (such as information learned
from the link layer) should be used. SCTP also has no mechanism to
deal with dynamic changes to the set of available addresses.
==> I think there is this "add-ip" extension to SCTP -- the standardization
status of which I'm not familiar with -- but they have at least started to
look at the problem space.
Network attachment procedures are also relevant for multihoming. The
IPv6 and MIP6 working groups have standardized mechanisms to
dynamically learn about new networks that a node has attached to,
==> I don't think IPv6 WG has standardized anything on this space. Vanilla
RFC2461 does not count as it's not sufficient to tell whether you've
attached to a new link?
o ICMP error messages. Given the ease of spoofing ICMP messages,
one should be careful to not trust these blindly, however. Our
suggestion is to use ICMP error messages only as a hint to perform
an explicit reachability test, but not as a reason to disrupt
ongoing communications without other indications of problems.
==> actually, robust implementations have long since started properly
verifying the ICMP messages. For examples, as
draft-gont-tcpm-icmp-attacks-00.txt describes, you can protect against ICMP
attacks against TCP by verifying that the ICMP message includes the correct
port numbers, seq/ack numbers etc., so that only (practically)
on-the-path attacker could have generated them.
There's not much UDP can do, because there's not much ICMP does to UDP, but
something could be possible there as well, I'd guess.
Architecturally, a number of questions arises. One simple question
is whether there needs to be communications between a multihoming
solution residing at the IP layer and upper layer protocols? Upon
changing to a new address pair, transport layer protocol SHOULD be
notified so that it can perform a slow start.
==> using 'slow start' might be a bit accurate, because there's not much
slow in 'slow start' except the name. Did the draft mean a really slow
start, or was aggressive probing OK as well?
5.2 State Machine for Address Pair Selection
==> the state machine doesn't appear to have the (trivial) even where adding
a new pair would happen during testing the primary pair state.
Our suggestion is that nodes MUST first consult RFC 3484 [5] policy
tables to determine what combinations of addresses are legal from a
local point of view, as this reduces the search space.
==> you're probably referring to extending RFC 3484 somehow, because AFAIR
it can't be used like this. (Or were you referring to adding some
destination host-specific policies in the table?)
editorial
---------
of useful terms and discusses them, and xref target='transport'/>
==> reference gone bad
o The address is a global unicast or unique site-local address [8].
==> s/site-//
(Note that this notification can not
be done in protocol designs where the end points are not the final
hosts, such as where a gateway is used.
==> add ")" at the end
Note that due to potentially asymmetric connectivity, both sides
have to perform their own tests, and make their own primary pair
selections.
An action to reset a timer so that it will send an event after a
specified time.
==> extra space there..
This process result in a combinatorial explosion when there are many
==> s/result/results/
[16] Nikander, P., "End-Host Mobility and Multi-Homing with Host
Identity Protocol", draft-nikander-hip-mm-02 (work in
progress), July 2004.
==> I was thinking this had just become hip WG document, but I may have been
mistaken..
================================
Shim layer:
substantial
-----------
The context state in this approach is maintained per remote ULID i.e.
approximately per peer host, and not at any finer granularity. It
might make sense to merge the context state for multiple ULIDs
assigned to the same peer host, but this is for further study.
==> this spec seems to be silent about demultiplexing of external inputs
which relate to an existing session, but do not have existing per peer host
state. Example: ICMP unreachable message sent by a router pertaining to a
packet sent (and mangled by the shim layer) by the host. These need to be
dealt with somehow as well.
In practice, this would seem to be creating a 1:1 NAT, and requiring to go
down to the application payloads (e.g., stuff inside the ICMP message) as
well. This needs to be considered explicitly, and discussed with pros/cons
prominently.
The approach makes no assumption about the reverse tree since the
approach does not use it. However, applications might rely on the
reverse tree whether multi6 is used or not.
==> across different documents, I think there have been some inconsistancies
regarding this, e.g., as a means to find new or different locators by doing
reverse+forward lookups. What's the real story here?
(I think the shim approach does not require DNS in and of itself, but when
something gets broken, like when applications start doing more advanced
stuff, DNS is a way which could "come to the rescue"..)
8.1. Initial Context Establishment
[...]
When the policy is triggers, which could be on either A or B, an
initial context establishment takes place. This exchange might
fail should the peer not support the multi6 protocol. If it
succeeds it results in both ends receiving the locator sets from
their respective peer, and the security mechanism provides some
way to verify these sets.
==> s/triggers/triggered/ (or something)?
==> is it possible / feasible to merge this functionality with steps 1 and
2? I.e., this does not discuss whether the set-up could be piggybacked upon
earlier messages? There's plenty of space in those TCP conn. establishment
messages, for example..
semi-editorial
--------------
This document outlines an approach to solving IPv6 multihoming in
order to stimulate discussion.
==> sigh.. this must have been written in haste, because there is no chance
it is going to solve all the problems; just one rather important one (for
small sites at least)
Note that the hard issues with ULIDs is
how to perform the mappings between them and the locator sets. With
routable ULIDs the AAAA resource record set provides this "mapping".
Non-routable ULIDs would need similar mechanisms, which is probably
feasible for unique local addresses based on prefixes that are
centrally assigned.
==> see my comments on referrals. The assumption of ULAs being central is
bogus; it may be that no support will be possible for non-central ones is
possible (and not necessarily even on central ones, depending on whether
reverse tree gets built or not), but this needs to be stated explicitly.
This approach would reduce the overhead. On the other
hand, this approach would cause changes in the available MTU, since
packets that include the Extension Header will have an MTU 8 octets
shorter.
==> please also remember that in case if the required overhead changes
(e.g., overhead is only needed in some special cases), it might be that the
additional overhead triggers failure conditions which may be difficult to
debug. Not a major problem, but something to bear in mind.
[MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST):
AN EXTENDED PROPOSAL", draft-crocker-mast-protocol-01.txt,
October, 2003.
==> I believe this was superseded by CELP.
editorial
--------
Ls(A) is the locator set for A, which consists of L1(A), L2(A), ...
Ln(A).
==> s/L1/locators L1/
This implies that the ULID section is performed as today's default
==> s/section/selection/
Should not all locators be working when the communication is
initiated some extra complexity arises, because the ULP has already
been told which ULIDs to use. If the locators that where selected to
be ULIDs are not working and the multi6 shim does not know of
alternate locators, it has to choice than to have the application try
a different ULID.
==> s/where/were/
==> s/choice/choose/
However, this approach
requires support form the initiator node, implying that only upgraded
nodes will obtain improves fault tolerance while legacy nodes that
don't support the new DNS record will still obtain reduced fault
tolerance capabilities.
==> s/form/from/
==> s/improves/improved/
DNS to prevent them from every being used as ULIDs. The applications
==> s/every/ever/
The host-pair context is established on each end of the communication
when one of the endpoints performs the multi6 signaling (the 4-way
handshake referred to in [M6FUNC].
==> s/]/])/
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings