[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on multi6dt documents


Thanks for the comments.

Pekka Savola wrote:

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. 

Did you see issues in addition to the ones you explicitly listed below?

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

It might make sense clarifying this.
If you are using some security, such as IPsec or TLS, then it is true that the application will have better certainty about the identity of the peer in many cases, but the identity it has certainty about isn't the IP address but the identity to which the certificate is bound.

Stated differently, if I use IP address X in here at the IETF with IKE/IPsec and my cert, and you later use the same IP address with IKE/IPsec and your cert, it doesn't mean that the IP address refers to the same identity in the two cases.


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

Yes, but the hard part is, since the 2^63 number of RFC3041 addresses per link can't be prepopulated in the DNS, is that they names need to be *created* in the DNS. With DNSsec we have operational understanding of what it takes to authorize the *update* or RRs for an existing name, but little or no experience with the creation of new names.

It isn't clear to me if the above document recommends that the DNS servers sythesize records (which has issues with DNSsec) or something else.

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.


I suspect it's harder than that.

   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.


I agree the text is not as clear as it should be on the ULAs.



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

I don't see it - looks like the ID expired.

================================

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.


Good point.

In practice, this would seem to be creating a 1:1 NAT,

Not quite (and whether using the term "NAT" is helpful is a separate question - folks associate it with middleboxes that mess with DNS and other stuff).

The sender needs to be able to demux a packet it sent based on the first 64 bytes.

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.

But it's part of the endpoint and not a middlebox. That implementations have code which removes various things the IP layer might have added (fragmentation headers, destination options, etc) in the transmit path before passing the packet to TCP for demuxing on the port numbers shouldn't be a big deal, should it?
Or am I missing something?

  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? 

Across which documents? draft-*-multi6dt-* documents?


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

Good question. Some of the tricky parts of piggybacking (putting two payloads in the same packet) relates to interaction with IPsec policy especially if the policy is applied by security gatways.

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)


But the text at least stimulated discussion :-)


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.

Yes.
But since this is added by the sender and not something in the middle
many of those concerns (such as ICMP too big not getting through) do not apply. But we should discuss this further in the draft.

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

I think they are separate ideas. CELP has the common pool idea, and MAST provided ideas like the deferred context establishment.

   Erik