Subject: RE: (ngtrans) shipworm discussion and last call

From: "Christian Huitema" <[email-masked]>
Date: Wed, 26 Sep 2001 08:10:21 -0700

> >Please send your comments to the ngtrans list.
> 
> 	there were a lot of comments, after London IETF, about possible
> 	security risks (mainly from Pekka).  should that be 
> issued again?

These comments have been taken in consideration in the draft, which was
revised after the IETF. The main issue was the use of automatic
tunneling, such as Shipworm, as a relay to "launder" denial of service
attacks. The draft now includes very clear protections in that regard:
for packets received over UDP, relays must check that IPv4 the source
address and UDP source port match the prefix of the IPv6 source address;
clients must only accept packets that come from relays, i.e. from the
anycast address, or that the IPv4 source address and UDP source port
match the prefix of the IPv6 source address. In addition, both relays
and clients must check that the IPv4 address embedded in the prefix is a
valid unicast address, which prevents possible attacks to local hosts. 

-- Christian Huitema

---

From: Jung Cyndi-ACJ099 <[email-masked]>
Date: Wed, 26 Sep 2001 14:06:55 -0500

The restriction on sourcing from an anycast address has been in the IPv6 address 
architecture for a long time - and people have spent lots of WG time trying to use 
anycast usefully while complying with this restriction.  I think the "very folk"
that created the ban in IPv6 are different from those who are proposing to use it 
in IPv4 to support IPv6 transition solutions, but I don't recollect how it got into 
the addressing architecture in the  first place.  

Any historians listening?

Cyndi

-----Original Message-----
From: Randy Bush [mailto:[email-masked]]
Sent: Wednesday, September 26, 2001 11:34 AM
To: Pekka Savola
Cc: NGtrans List
Subject: RE: (ngtrans) shipworm discussion and last call

if sourcing from an anycast address is to be banned, i find it amusing that
the very folk who would ban it in v6 propose to use it in v4.  perhaps there
is a lesson here.

randy

---

From: Jung Cyndi-ACJ099 <[email-masked]>
Date: Wed, 26 Sep 2001 17:23:16 -0500

I have a few comments on the document - I don't think they touch any "deep" issues, but
they may be helpful.

Comment 1:
Section 4, last paragraph before 4.1, the word "adequate" is used - I think "appropriate"
is a better single word to use, but possibly a more verbose "IPv4 address and UDP port
(per this specification)" would be better.  "Adequate" just doesn't work.

Comment 2:
Section 4.1.4 - the description of the "bubble" used to create a direct path between
Shipworm clients - I believe the rules for building the IPv4 header are wrong:

- IPv4 source address: the Shipworm mapped address of the sender
- IPv4 destination address: the IPv4 address of the target

I think they need to be reversed (with respect to which uses the Shipworm mapped address
and which uses the IPv4 address).  Certainly, when the packet is received, the IPv4
source and destination will have these values, but when the packet is formed the
IPv4 source will be the "IPv4 address of the sender" and the IPv4 destination will be
the "Shipworm mapped address of the target".  To be fair, the section does not state that
this is the description of the packet when it is received - which I suggest would help
clarify the formation of the "bubble", to show both how it is formed and how it differs
when it is received.

Comment 3:
Section 4.2.4 - in the last paragraph of this section, it begins "After sending receiving
a Router Advertisement" - it should just say "After receiving a Router Advertisement".

Comment 4:
Section 4.3.1 point 5 says "If the IPv4 source" and it really should say "If the IPv4
destination"

Comment 5:
Section 4.3.1 after the 6 points, when the Shipworm server determines that it is about
to forward a packet to a Shipworm client, it then validates the Shipworm address by
testing that the mapped address is a global unicast address.  The paragraph just says
"destination IPv4 address is in the format of a global unicast address" - but doesn't
say where that address came from.  I could probably find dozens of places where it
isn't explicit enough which IPv4 address is being discussed - this is certainly one 
place.

Comment 6:
Section 5.1 - in the example, I hope it was an intentional error to claim that 2860 is
the headecimal representation of the decimal number 4096 - I caught it :-)
 
I'm sure there is more.  It's an interesting idea - I'm glad I don't use dial-up anymore :-)

Cyndi

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 26 Sep 2001 17:21:17 -0700

Thanks, Cyndi.

I am taking your comments in a revised draft. I also received a set of
comments from Pekka, mostly editorial. I will have a new drat ready by
the end of the week; more comments from more reviewers are indeed
welcome!

You mention that there are "dozens of places where it isn't explicit
enough which IPv4 address is being discussed."  I would really
appreciate a list.

Glad you noticed the poor phrasing of bullet 5 in 4.3.1; it was in fact
a leftover of a previous edition; the whole bullet need in fact to be
removed.

-- Christian Huitema

> From: Jung Cyndi-ACJ099 [mailto:[email-masked]]
> Sent: Wednesday, September 26, 2001 3:23 PM
> To: 'Bob Fink'; NGtrans List