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