Subject: RE: (ngtrans) I-D ACTION:draft-ietf-ngtrans-shipworm-00.txt

From: "Christian Huitema" <[email-masked]>
Date: Wed, 29 Aug 2001 13:53:55 -0700

Thanks for the detailed review, Pekka. I will incorporate most of your
edits in the next revision. I would like comments on two issues that
were raised during the discussion in London:

1) Should we randomize all the timers, e.g. randomly pick an actual
refresh interval between 75% and 100% of the nominal value?

2) Should we incorporate some text on congestion control, e.g. mention
that there is congestion control on the transported packets...

Detailed answers to your comments follow.

> 2 Definitions
> 
> ==> Should add Shipworm secondary port here.

Will do.

> 3.3 Non requirement of permanent addresses
> 
> The absence of permanent addresses can be palliated by "name
> services" or "rendezvous services" through which the node can
> publish its address of the moment to its peers; for example, the
> nodes can be
> 
> ==> something left out.. :-)

Yes. I will mention Sip and dynamic DNS.

> ==> should that be "Non-requirement"?  Also, this would also be
> applicable
> to 6to4; should the title be something more specific?

This is about Shipworm; the problem here is worse than in RFC3056. 6to4
provides a stable address if the underlying IPv4 address is stable,
which can often be the case; shipworm could only provide a stable
address if the NAT mapping was stable, which is very unlikely.

> ==> DynDNS etc.  One should very much avoid embedding plain IPv6
> addresses
> everywhere (not even 6to4 IMO), especially as chancy as this.
> 
> 4.1.4 Shipworm bubble
> 
> s/as follow/as follows/.
> 
> (note: some of the lists end with period here and elsewhere in the
> doc;
> perhaps better remove it/add it everywhere)

Done.

> 4.2.2 [Client] Packet reception
> 
> ==> If there is no IPv6 packet inside encapsulating IPv4, I think it
> must be discarded as with Server.  (this is implicit in the spec).
> 
> ==> s/silently rejected/silently discarded/.

Done.

> ==> should target ipv4 and ipv6 addresses also be checked?

Target Ipv4 & UDP port is implicitely checked: we are only concerned
with packets received on the Shipworm service port. I can see why we
would want to check that the destination IPv6 address matches the local
Shipworm prefix, but I would rather wait for other comments if someone
disagrees.

> 4.2.5 Sending Shipworm Bubbles
> 
> s/MUST creates/MUST create/

done.

> 4.2.6 Optional Refresh Interval Determination Procedure
> 
> If the secondary qualification succeeds, the maximum refresh
> interval is set to 960 seconds
> 
> ==> why not just 900 seconds ie. 15 minute?  Being able to more easily
> take 75% of it?  Feels like some other rule might be better in this
> case
> if this is so..

16 minutes is just as good as 15, and is a power of two, which yields
faster convergency.

> 6) if the procedure has not concluded, perform the maintenance
> procedure on the secondary port, which will reset the date and time
> of the last interaction on the secondary port, and may result in the
> allocation of a new Shipworm secondary address; this would not affect
> the values of the refresh interval, candidate interval or maximum
> refresh interval.
> 
> ==> what Shipworm secondary address?  This term is not used anywhere
> else
> in the draft.

Corrected to shipworm IPv6 secondary address.

> 4.3.1
> 3)	If the IPv6 source address is a Shipworm IPv6 anycast address,
> if
> the IPv4 source address and UDP source port match the values
> embedded in the IPv6 source address, and if the IPv4 source
> address the packet MUST be accepted.
> 
> ==>
> 
> The thought has been left unfinished :-)
> 
> Should s/a Shipworm IPv6 anycast address/a Shipworm IPv6 address/ ?
> 
> There is something missing in the sentence 'IPv4 source address
> the..'.
> Seems like leftover from moving to 2).

Yes. Corrected. The basic idea is that, since relays send their packets
directly to the destination, the shipworm servers should never receive
packets from shipworm relays, unless the packets are actually destinated
to the server itself.

> 
> 4)      If the IPv6 source address is the IPv6 unspecified address,
> and
> if the IPv6 source address is the Shipworm IPv6 anycast address,
> the packet MUST be accepted.
> 
> ==> I believe the second source address should be destination address.

Corrected.

> If the destination address is not a Shipworm IPv6 address, the
> packet should be relayed to the IPv6 Internet using regular IPv6
> routing.
> 
> ==> if you put 'fe80::1' as ipv6 destination address, or ::127.0.0.1,
> or
> whatever, will you able to breach into the Shipworm Server?  Should
> there
> be some sanity checking, like outlined by me in 'practical 6to4
> security
> rulesets'?
> 
> Tunneling, especially the automatic kind, is always chancy...

Yes, I will add that the destination address should be a global scope
IPv6 address. An obvious question is, do we allow multicast? This is not
very high on my list of priorities, but I know that some members of this
group may have a different opinion.

> 4.3.2   Processing of router solicitations
> 
> Before relaying packets received on the Shipworm port, the Shipworm
> server MUST perform the security tests described in section 7.
> 
> ==> These have now been moved to 4.3.1, right?

Yes, this is a leftover.

> 4.3.5   Fault isolation
> 
> ==> shouldn't ping6/traceroute6 to ipv6 shipworm anycast address in
> the
> end give you the non-anycast ipv6 address of the relay, as anycast
> cannot
> be used as a source?  Of course, if the server doesn't work so far to
> get
> even there, this won't yield much.

I would rather not specify this. Ping6/traceroute6 should work just as
specified in standard IPv6.
 
> 4.4	Shipworm Relay specification
> 
> ==> The mandatory security checks referenced from chapter 7 aren'
> mentioned here yet.

Corrected. Essentially, relays need to check that the IPv4 address is a
globally unique unicast address.

> 5)	In all other cases, the packet MUST be rejected.
> 
> ==> rejected or discarded?  If rejected, how?  ICMP destination
> unreachable: address unreachable (1:3)?  If source is believed to be
> forged or otherwise tampered, is it sensible to try to send ICMP
> packets
> there?

Corrected to silently discarded.

> If the IPv6 destination address is a valid Shipworm IPv6 address,
> the Shipworm Server MUST check that the IPv4 destination address is
> in the format of a global unicast address; if this is not the case,
> the packet MUST be silently discarded.
> 
> ==> Should this check happen before Shipworm server processes the
> packet
> if it was meant for it?

Corrected.

> 5.5
> Scaling, failover and access control
> 
> ==> This is a leftover note.

Corrected.

Thanks again for the comments.

-- Christian Huitema

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Aug 2001 10:19:49 +0300 (EEST)

> refresh interval between 75% and 100% of the nominal value?

Personally, I'm not sure of the gains.  This is an optional feature after
all, and if you are using Shipworm, you should not be concerned whether
refreshing occurs between e.g. 500 or 600 seconds.  It's one small packet,
sent pretty rarely, after all.

AFAICS, this would only be useful in "optimizing the last 25%" which, IMO,
would be rather pointless, as by then the refreshing happens very rarely
anyway.  Predictability/simplicity is good.

If there are any other uses for randomized value, it might be interesting
to hear of them.

> that there is congestion control on the transported packets...

Depending on what's transported, there may not be -- but I don't see how
this is relevant with tunneling techniques, as long as we don't use TCP as
the tunnel mechanism.

Or was there some more specific reason why the concern was raised?

> address if the NAT mapping was stable, which is very unlikely.

yes, like NAT box crashes and loses all mappings ... :-)

> Shipworm prefix, but I would rather wait for other comments if someone

One issue here is, do we want to specify Shipworm for only one interface
(one IPv6 prefix)?  Probably, to simplify it.

> 16 minutes is just as good as 15, and is a power of two, which yields

Yes, but two points:
 1) if there's randomization between 75 and 100%, there is no added
benefit of a power of two (I'm not sure if I see one anyway as you take
averages of it etc., not just e.g. halve until 1)
 2) we don't count this as minutes...

> Corrected to shipworm IPv6 secondary address.

Sorry again, what 'secondary address'?  There is no mention of such in the
draft.

> group may have a different opinion.

It's a toughie, sure.  At least link-local, and perhaps site-local,
multicast could be banned.

Here, we must remember that if we specify this too tightly, we don't have
any flexibility in the future as all the relays/servers etc. would have to
be changed -- so if unsure about global-scope multicast, perhaps it would
be better to leave it unspecified for now.

On the other hand, the Shipworm mechanism is potentially a bit
unstable/chancy and/or transitionary anyway, so one could argue we _should
not_ start building too huge toolbox of NAT-piercing techniques in the
future anyway, rather focus on making IPv6 happen.

> specified in standard IPv6.

Makes sense.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Alain Durand <[email-masked]>
Date: Thu, 30 Aug 2001 09:36:12 -0700

> If there are any other uses for randomized value, it might be interesting

Randomization prevent synchronisation. You do not want a large number of
host who started at the same time to refresh in sync.

> (one IPv6 prefix)?  Probably, to simplify it.

Shipworm is a transition mechanism to get around the problems caused by NAT.
The simpler the better.

> future anyway, rather focus on making IPv6 happen.

I  agree 100%.

    - Alain.