Re: Comments on multi6dt documents

On Tue, 9 Nov 2004, Erik Nordmark wrote:
> 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?

I might have to re-read it again because the ICMP issue was so obvious 
I started thinking whether some others would also be lurking out there 
and just deferred that to 'have you checked the things to think about' 
:)

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

With this clarifying example (the temporal element to the address 
ownership) I think the potential issues this brings up are clearer. 
Thanks.

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

Umm, I don't think DNSSEC (except some basic components it may 
use) really deals that much on DDNS updates, but the point stands that 
there has been, AFAIK, relatively little protocol work on adding new 
records.

I'm not sure of the protocol itself, and the more generic case, but I 
believe the reverse DNS issue could be solved, in the 
important practical cases, using just an implementation approach.

That is,
  1) require that the server be located at the same site as the updater 
(relatively reasonable)
  2) that hopefully some amount of address spoofingi protection has 
been deployed on the site: just uRPF on the subnet basis is sufficient
  3) make the hosts add the rfc 3041 reverses directly to the zone, 
without any security
  4) the dns server allows such insertion only if there are no existing 
records, and the update comes from the IP address corresponding to the 
reverse record
  5) the records don't need to be removed by the hosts, only by a 
clean-up process by the server

Not perfect, there are certainly some corner cases here, but I guess 
this should be at least sufficient to experiment with DDNS reverse 
insertions if that was deemed to be useful.

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

If it's important to provide *anything* (to work around broken apps 
etc.) instead of something particularly useful, a wildcard reverse 
could be used.  Not applicable here, of course.

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

OK, I'll agree that particularly in environments where you are not 
comfortable with making some perhaps significant assumptions this may 
have, well, "issues". :)

Still, it would seem to be useful to try to experiment with this, but 
this is a subject for another forum.

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

Agree that NAT is a loaded word and better avoided.  I used it to 
refer to the fact that address mapping seems to be required, as well 
as rather NATty behaviour or looking at the payload and interpreting 
the content in some manner, and trying to mangle it.

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

How do you derive 64 bytes?  For example, doesn't an ICMP error 
recieved over v6 require at least 40 (ip6) + 8 (icmp6) + 40 (ip6) = 88 
bytes at the very least, but additional bits e.g. from the extension 
headers, possible destination options or whatever.

Unless we can make some simplifying assumptions here it seems like 
bringing up issues described in section 2.1.9 of 
draft-savola-v6ops-security-overview-03.txt and prior to that in a 
different draft -- i.e., the nodes must be able interpret and process, 
or skip over -- all the possible headers out there.

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

Just demuxing the packet (and doing reverse mapping if needed) would 
be one thing, but don't you also have to parse inside the packet and 
translate that back as well?  Then the implementation should have to 
know which protocols to parse and how, i.e., where the "juicy bits" to 
look are.

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

multi6dt, yes.  At least that's the impression I recall getting after 
reading especially the referrals, shim, and functional decomposition. 
I probably should try to focus more on this the next time I check 
them.

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

OK.  Just an approach to consider; some might consider it important, 
some not.  I haven't really formed an opinion.

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

That's good :)

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

Agreed.  Protocols such as UDP probably incur fragmentation and TCP 
just adjusts.

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

Ok, could be; that was just the recollection I had, which was likely 
wrong because I've read neither in detail.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings