Subject: Comments on multi6dt documents

From: Pekka Savola <[email-masked]>
Date: Tue, 9 Nov 2004 02:36:42 +0200 (EET)

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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 09 Nov 2004 10:56:44 -0800

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

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

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.

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

> and even if they did, the DNS zone admins might not allow the required DNS

I suspect it's harder than that.

> that's quite different from this silent assumption.

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

> ==> wasn't this an RFC already?

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

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

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?

> reverse+forward lookups.  What's the real story here?

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

> earlier messages?  There's  plenty of space in those TCP conn. 

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

But the text at least stimulated discussion :-)

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Nov 2004 21:00:18 +0100

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

The latest draft was -10, which was approved by the IESG
in November 2003, but somehow it has got lost since then.
I've just sent a query to the IESG.

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 9 Nov 2004 21:40:04 +0100

Hi Pekka,

thanks for the feedback
some replies online

El 09/11/2004, a las 1:36, Pekka Savola escribió:
> be passed to the peers out of band

what do you mean by out of band?

i mean the CGA_PDS has to be communicates to the other end, but it will 
be sent in clear through the multi6 protocol.
i.e. there is no need to hide the CGA_PDS to obtain the security of HBAs

ok?

>  because otherwise they can't perform

I agree that an explanation of how the HBAs could be used in a multi6 
protocol is needed in the draft.
I was thinking to include an example in an appendix

> patent applications were, i.e., whether HBA would be covered as well.

Agree, but the chairs suggested to first figure out if HBA are good and 
then go for the IPR stuff, which imho is a good approach

> which should be split up.

ok, i will fix this

thanks, marcelo

---

From: Eliot Lear <[email-masked]>
Date: Tue, 09 Nov 2004 15:50:10 -0500

I killed the NSRG draft.

I did so because after three rounds with the RFC Editor over a period of 
two years I believed the environment had changed sufficiently to require 
revisiting of existing work.  The concepts in the draft remain valid.

Eliot

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 9 Nov 2004 23:29:01 +0100

> must be actively kept in sync.  This is an area which is not often the

I think that when it's said that something should be done, it's implied 
that this should be done correctly.

> on-the-path attacker could have generated them.

We can't presume a multi6 implementation has such intimate knowledge of 
what TCP has been up to. Also, we need to be generic enough that 
non-TCP and even non-UDP protocols work reasonably well.

> Upon

> slow in 'slow start' except the name.

I think triggering slow start is pretty much all you can do to slow 
down TCP

> Did the draft mean a really slow start, or was aggressive probing OK 
> as well?

The properties of the new path are unknown so basically transports 
should behave as if the session is new after a rehoming even.t

> I.e., this does not discuss whether the set-up could be piggybacked 
> upon

The trouble is that if you put multihoming stuff between the IP header 
and the TCP header you may end up being filtered. Also, under most 
circumstances either the packets you may want to piggyback on are 
already filling up the MTU, or there aren't any. So the complexity 
needed for piggybacking is probably not receive a decent return on 
investment.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Nov 2004 03:57:37 +0200 (EET)

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

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

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

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

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

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

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.

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

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.

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

> But the text at least stimulated discussion :-)

That's good :)

> apply. But we should discuss this further in the draft.

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

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Nov 2004 03:59:53 +0200 (EET)

On Tue, 9 Nov 2004, marcelo bagnulo braun wrote:
>>  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
>
> i mean the CGA_PDS has to be communicates to the other end, but it 
> will be sent in clear through the multi6 protocol. i.e. there is no 
> need to hide the CGA_PDS to obtain the security of HBAs
>
> ok?

That's OK.  I just meant out of band in the sense that how it's done 
is probably external to the HBA protocol itself, it just needs to be 
shared with some mechanism.

>>  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.
>
> Agree, but the chairs suggested to first figure out if HBA are good and then 
> go for the IPR stuff, which imho is a good approach

Agree that this is probably a good pragmatic approach.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Nov 2004 04:14:32 +0200 (EET)

On Tue, 9 Nov 2004, Iljitsch van Beijnum wrote:
> I think that when it's said that something should be done, it's implied that 
> this should be done correctly.

The implication may be done, but one can still correctly argue that 
one can maintain forward and reverse tree in a manner that those don't 
match, as long as there are some records in either :).

Actually, operaionally, I'd guess this is a relatively big challenge.

>> ==> 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.
>
> We can't presume a multi6 implementation has such intimate knowledge 
> of what TCP has been up to. Also, we need to be generic enough that 

So, I guess this depends on where this failure detection code resides 
with regard to the ICMP message reception and parsing.

>> Did the draft mean a really slow start, or was aggressive probing OK as 
>> well?
>
> The properties of the new path are unknown so basically transports should 
> behave as if the session is new after a rehoming even.t

That's OK; put that justification to the draft alongside of the 
mention of slow start.

>> I.e., this does not discuss whether the set-up could be piggybacked upon
> The trouble is that if you put multihoming stuff between the IP header and 
> the TCP header you may end up being filtered.

Unfortunately, a very real possibility.  The tradeoff needs to be 
written down, of course

> Also, under most circumstances 
> either the packets you may want to piggyback on are already filling up the 
> MTU, or there aren't any. So the complexity needed for piggybacking is 
> probably not receive a decent return on investment.

Unless you piggyback on the TCP connection establishment messages 
which are known to be small enough to accommodate this.  That's the 
only realistic case for piggybacking benefits AFAICS.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 10 Nov 2004 09:49:53 +0100

On 10-nov-04, at 3:14, Pekka Savola wrote:

>> Also, under most circumstances either the packets you may want to 
>> piggyback on are already filling up the MTU, or there aren't any. So 
>> the complexity needed for piggybacking is probably not receive a 
>> decent return on investment.

> only realistic case for piggybacking benefits AFAICS.

This is especially the place where filtering would be most harmful, 
because you don't know whether lack of a response means you should 
retry without the multihoming header, or you should try a different 
address.

But I do agree there are advantages as well. If you want to set up 
security stuff that is susceptible to sniffing attacks, the first 
packet is the place you want to do it because an attacker with just 
sniffing capability can't inject a false packet for a legitimate new 
session, because the properties of new sessions aren't known until the 
first packet is transmitted.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 10 Nov 2004 07:43:56 -0800

> 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.
> 
> believe the reverse DNS issue could be solved, in the important 
> practical cases, using just an implementation approach.
> 
> That is,
>  2) that hopefully some amount of address spoofingi protection has been 
> deployed on the site: just uRPF on the subnet basis is sufficient

So which RFC that contains the above should I add to the references :-) :-)

Seriously, I think it would make sense to start writing this down with 
an eye to hosts which have multiple prefixes. Thus they want a temporary 
name which has AAAA records for one IP address for each of the prefix.
(The above procedure just handles a single AAAA record per name, which 
isn't sufficient to solve the issue.)

> this is a subject for another forum.

I know things in this space have been discussed in DHC in the past, but 
is there a WG that should work on this?

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 10 Nov 2004 08:03:57 -0800

> ownership) I think the potential issues this brings up are clearer. Thanks.

ok. I'll add it to the draft.

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

Per this definition I think header compression would be categorized as a 
NAT, because it mangles the packet. The difference with multi6 and 
header compression is that the mangling will be undone i.e. the output 
at the other end will be the same as the input. This isn't the case for 
NAT, which is why I think using that term here adds confusion.

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

I misremembered the ICMPv6 spec about the size of the returned offending 
packet. It will be more like 1000 bytes (as much of the offending packet 
that fits without exceeding 1280 bytes for the ICMP error).

> or skip over -- all the possible headers out there.

Are you saying the middleboxes will inspect, not the IP+ICMP part,  but 
the offending packet contained in the ICMP error?
There might be concern about adding an extension header to get e.g. 
IP+EXT+TCP and what that does to the packets in middleboxes, but the 
context of this piece of the discussion is the ICMP errors, right?
If the middlebox lets through IP+EXT+TCP then presumably it will allow 
the error which is IP+ICMP+IP+EXT+TCP in the reverse direction.

> 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 

Yes, the implementation needs to be able to pass the indication that an 
ICMP error was received to the correct ULP "connection", which involves 
finding the ULIDs that were used before the shim did its work on the 
xmit side.
The details of this depends on how the internal interfaces in the 
implementation for delivering notifications about ICMP errors to the 
ULPs; does it deliver the actual ICMP packets or something more abstract,

So it involves writing code in an implementation and should be noted in 
the draft. Is it hard? No.

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

Yes, sending e.g. 8k NFS packets over UDP has been observed to cause 
fragmentation :-)

But since the added bytes are on the sending host an implementation 
should be able to do a good job of fragmenting things. Thus there isn't 
a need to end up with one 1500 byte piece followed by an 8 byte fragment 
followed by 1500, 8, 1500, etc.

    Erik

---

From: Francis Dupont <[email-masked]>
Date: Wed, 10 Nov 2004 17:16:28 +0100

About DDNS and DNSSEC: they don't work well together because DDNS
requires private (zone) keys are online to update signatures when
DNSSEC works well and safer with offline keys.

Regards

[email-masked]

PS: I locally solved this operational issue with a dedicated DDNS sub-zone.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Nov 2004 17:28:14 +0100

Erik Nordmark wrote:
>> really deals that much on DDNS updates, but the point stands that 

When we summarize the next steps for multi6, we should include
a gap analysis, and this should be part of it.

    Brian

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 10 Nov 2004 17:32:29 +0100

> PS: I locally solved this operational issue with a dedicated DDNS sub-zone.

I guess this is the solution used in most cases. Many people like the
format of their zones and ddns updates destroy the formatting of the
zones file (at least bind does this). Thus you make CNAMES from the main
zone to the subzone without bothering the clean zone. Isn't this part of
an RFC or BCP actually?

Greets,
 Jeroen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Nov 2004 19:58:31 +0100

At the moment I think we are hoping the multi6 solution
will be DNS-agnostic.... in which case this topic is out of
scope, I guess.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Wed, 10 Nov 2004 17:55:44 -0800

Iljitsch van Beijnum wrote:
...
> I think triggering slow start is pretty much all you can do to slow down 
> TCP

You mean slow-start restart, right?

I.e., you want to behave like you lost enough information that you start 
from the ground-state with congestion control. It should act like 
restarting after idle, more than just 'going into slow-start'.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Nov 2004 15:43:23 +0200 (EET)

On Wed, 10 Nov 2004, Erik Nordmark wrote:
>> Unless we can make some simplifying assumptions here it seems like bringing 
>> up issues described in section 2.1.9 of 
>> different draft -- i.e., the nodes must be able interpret and process, or 
>> skip over -- all the possible headers out there.
>
> Are you saying the middleboxes will inspect, not the IP+ICMP part,  but the 
> offending packet contained in the ICMP error?

I don't think this is a problem.

> IP+EXT+TCP and what that does to the packets in middleboxes, but the context 
> of this piece of the discussion is the ICMP errors, right?
> If the middlebox lets through IP+EXT+TCP then presumably it will allow the 
> error which is IP+ICMP+IP+EXT+TCP in the reverse direction.

Agreed.  I wasn't sure of the context, just that IP+EXT+whatever might 
not do it.  Destination options however provide the facilities today 
for skipping over them without making assumptions; this might not in 
practice be any better though.

>> 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.
>
> Yes, the implementation needs to be able to pass the indication that an ICMP 
> error was received to the correct ULP "connection", which involves finding 
> the ULIDs that were used before the shim did its work on the xmit side.
> implementation for delivering notifications about ICMP errors to the ULPs; 
> does it deliver the actual ICMP packets or something more abstract,
>
> So it involves writing code in an implementation and should be noted in the 
> draft. Is it hard? No.

So, the demux code needs to deal with ICMPv6 address translation. 
What about other protocols?  Do we want to care for the others which 
might be doing similar things, or we just say 'just do the referral 
thing'?

The fact this is an ALG in a sense should possibly be stated, with the 
caveat that we're assuming that there aren't other equally 
"fundamental" protocols where you shouldn't be required deal with the 
full referral process.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Nov 2004 15:58:23 +0200 (EET)

On Wed, 10 Nov 2004, Erik Nordmark wrote:
>>  3) make the hosts add the rfc 3041 reverses directly to the zone, without 
>> any security
>>  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.
>

:-) -- actually, I had been asking on dnsop whether the DNS update 
specific issues should be split to a separate, new document (whether 
informative or normatively referenced).  That might allow them to be 
analyzed and experimented a bit further.. maybe even documenting the 
procedure described above :).

Unfortunately, the draft is already past the IESG, resolving Thomas's 
concerns, (one of which was the length, though), so while it 
definitely isn't too late for this -- if folks would see that as a 
good thing -- it's still something I'd rather have started earlier. 
But that's life :).

> Seriously, I think it would make sense to start writing this down 
> with an eye to hosts which have multiple prefixes. Thus they want a 
> temporary name which has AAAA records for one IP address for each of 
> the prefix. (The above procedure just handles a single AAAA record 
> per name, which isn't sufficient to solve the issue.)

A very important thing IMHO would be doing actual testing and 
experimentation on this, which might also implementing some minor 
features at the DNS server if needed.

>> Still, it would seem to be useful to try to experiment with this, 
>> but this is a subject for another forum.
>
> I know things in this space have been discussed in DHC in the past, 
> but is there a WG that should work on this?

Precisely.  This clearly falls under the dnsop WG responsibility 
(IMHO).  It just requires that folks are interested in pursuing this 
work.

If there are people who are interested in this -- particularly for 
doing some actual testing etc. -- I'd suggest speaking up here, at 
dnsop, or to me directly.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 11 Nov 2004 11:58:49 -0800

Pekka Savola wrote:

> not do it.  Destination options however provide the facilities today for 
> skipping over them without making assumptions; this might not in 

If a firewall is built on the philosophy to be conservative it will not
let anything new through, whether it is a new payload type, a new
option, or whatever.

> So, the demux code needs to deal with ICMPv6 address translation. What 
> about other protocols?  Do we want to care for the others which might be 
> doing similar things, or we just say 'just do the referral thing'?

What other protocols do you have in mind?
We already know things that do explicit QoS setup needs to be locator 
aware since the routers will see packets containing locators.
There might be other signaling protocols that fall in the same category, 
but they would all be about signaling something to routers or middleboxes.

And we have things that only operate on the locators, such as the 
routing protocols, hence need no change at all.

And ICMP errors (or other error or informational packets generated by 
routers) needs special handling.

But I don't see anything else.

Oh - for multicast applications I think the only sensible thing is to 
use locators. Protocols like RTP already carry an end-to-end ID so it 
should be fine to rewrite the source IP address field for those without 
the application being upset, but it is harder to know whether the 
receivers can undo the rewrite.

> caveat that we're assuming that there aren't other equally "fundamental" 
> protocols where you shouldn't be required deal with the full referral 
> process.

Why do you wish to confuse things by calling it an ALG? It is a local 
matter for the implementation how it demuxes ICMP errors. ALGs and NATs 
make people think of middleboxes which perform transformations which can 
not be reversed.

    Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Nov 2004 13:22:06 +0200 (EET)

Following up on an old message, sorry...

On Thu, 11 Nov 2004, Erik Nordmark wrote:
>> Agreed.  I wasn't sure of the context, just that IP+EXT+whatever might not 
>> do it.  Destination options however provide the facilities today for 
>> skipping over them without making assumptions; this might not in practice 
>> be any better though.
>

True .. but firewalls of today don't even have a _chance_ of skipping 
over the extension header, even if they, or their administrators would 
want that (well, if the extension header is in TLV format, maybe then, 
because some firewalls assume the next ext headers are in TLV). 
Destination options at least allow that possibility.

[...]

Right out, I can't think of anything else than ICMP and multicast 
(which you already mentioned), but that doesn't of course mean those 
kind of protocols might not exist.  Therefore I think it would make 
sense to put this sufficiently clearly in the document that people 
need to keep in mind that there may be some protocols which might call 
for special handling.

> Why do you wish to confuse things by calling it an ALG? It is a local matter 
> for the implementation how it demuxes ICMP errors. ALGs and NATs make people 
> think of middleboxes which perform transformations which can not be reversed.

Sorry, I was just trying to figure out a term which says, "requires 
the host's shim layer and possibly some weirder middleboxes (like 
stateful firewalls, when they want to figure whether to pass this 
error in or not) have knowledge of applications' semantics [and if 
there are new such applications, requiring that this application 
knowledge to be updated], to be able to mangle the addresses inside 
the payload correctly."

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 19 Nov 2004 10:52:27 -0800

> Destination options at least allow that possibility.

If any future extension headers follow the canonical format:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Next Header  |  Hdr Ext Len  | ....
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

then one can build firewalls that are liberal in what they accept.
But I still think this is moot because firewalls by nature will be 
conservative in what they accept.

> Right out, I can't think of anything else than ICMP and multicast (which 
> you already mentioned), but that doesn't of course mean those kind of 
> protocols might not exist.  Therefore I think it would make sense to put 
> this sufficiently clearly in the document that people need to keep in 
> mind that there may be some protocols which might call for special 
> handling.

ok, I'll add some words.

>> matter for the implementation how it demuxes ICMP errors. ALGs and 
>> NATs make people think of middleboxes which perform transformations 
>> which can not be reversed.
> 
> 
> Sorry, I was just trying to figure out a term which says, "requires the 
> host's shim layer and possibly some weirder middleboxes (like stateful 
> firewalls, when they want to figure whether to pass this error in or 
> not) have knowledge of applications' semantics [and if there are new 
> such applications, requiring that this application knowledge to be 
> updated], to be able to mangle the addresses inside the payload correctly."

It isn't "applications" - it is what I'd call "IP signaling protocols" 
or something like it; protocols which are not end-to-end but involve the 
routers along the path. ICMP errors from the routers, or RSVP signaling 
is what we currently have as examples. NSIS falls here as well.

    Erik

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Nov 2004 22:05:43 +0200 (EET)

On Fri, 19 Nov 2004, Erik Nordmark wrote:
> Pekka Savola wrote:
>> True .. but firewalls of today don't even have a _chance_ of skipping over 
>> the extension header, even if they, or their administrators would want that 
>> (well, if the extension header is in TLV format, maybe then, because some 
>> firewalls assume the next ext headers are in TLV). Destination options at 
>> least allow that possibility.
>

s/are liberal/can be configured to be liberal/ -- the point may be 
subtle but I believe it's rather important :)

>> firewalls, when they want to figure whether to pass this error in or not) 
>> have knowledge of applications' semantics [and if there are new such 
>> applications, requiring that this application knowledge to be updated], to 
>> be able to mangle the addresses inside the payload correctly."
>
> It isn't "applications" - it is what I'd call "IP signaling protocols" or 
> something like it; protocols which are not end-to-end but involve the routers 
> along the path. ICMP errors from the routers, or RSVP signaling is what we 
> currently have as examples. NSIS falls here as well.

Yes, IP signaling protocols is probably closer, but with some warning 
because there appear to be people out there who think "signaling" in 
the IP world means invariably IntServ-like QoS... :-/