Subject: Invalid IP in INIT/INITCAK message

From: Padmalochan Moharana <[email-masked]>
Date: Wed, 8 Sep 2010 12:55:06 +0530

Hi All,
What should be the behavior of the SCTP endpoint on receive INIT/INIT
ACK message with invalid IP (0.0.0.0 or 255.255.255.255)?
Should endpoint discard the received INIT/INITACK message and response
ABORT with error cause Unresolvable Address?

Br,
Padmalochan

---

From: Thomas Dreibholz <[email-masked]>
Date: Wed, 8 Sep 2010 10:49:35 +0200

Hi Padmalochan,

if the IP source address for an INIT or INIT_ACK is 0.0.0.0 or 255.255.255.255 
-- which is obviously an invalid source address -- it does not make sense to 
send an ABORT to this invalid address.

> ABORT with error cause Unresolvable Address?

Best regards
-- 
=======================================================================
 Dr. Thomas Dreibholz

 University of Duisburg-Essen,                   Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
-----------------------------------------------------------------------
 E-Mail:     [email-masked]
 Homepage:   http://www.iem.uni-due.de/~dreibh
=======================================================================

---

From: Padmalochan Moharana <[email-masked]>
Date: Wed, 8 Sep 2010 14:31:07 +0530

Thanks Thomas, But if INIT received from a valid address  but IPv4
Address parameter in that INIT message contains IPs 0.0.0.0 or
255.255.255.255  then should endpoint send ABORT to the sender of the
INIT or send INIT ACK message.

Br,
Padmalochan

---

From: Randy Stewart <[email-masked]>
Date: Wed, 8 Sep 2010 07:35:49 -0700

Padmalochan:

This really is an implementation decision...

We know of course such an address parameter is invalid.. however in a
ASCONF message it would be indicating "please add the src address of  
this packet". Of
course that is un-necessary on an INIT or INIT-ACK since its added  
auto-magically.

You really have two choices..
a) Be conservative in what you send and liberal in what you receive  
and just
    ignore the address and continue.

or

b) Discard the INIT or INIT-ACK. If you decide to discard the INIT I  
would send
    a ABORT() with an "unresolveable address" error. The INIT-ACK you  
could send
    an abort too if you wanted.. this would only be for a wireshark  
trace or such
    since the sender has no assoc.. but you would of course fail the  
assoc setup
    that the app had done.

The choice is really up to you.. but I think I would lean personally  
towards <a>

R

On Sep 8, 2010, at 2:01 AM, Padmalochan Moharana wrote:

> On Wed, Sep 8, 2010 at 2:19 PM, Thomas Dreibholz <[email-masked] 
> > wrote:
>> Hi Padmalochan,
>>
>> = 
>> = 
>> =====================================================================
>>  Dr. Thomas Dreibholz
>>
>> = 
>> = 
>> =====================================================================
>>
>

-----
Randall Stewart
[email-masked]

---

From: Chris Benson <[email-masked]>
Date: Tue, 14 Sep 2010 11:48:43 -0700 (PDT)

Dear Padmalochan,

Before considering an appropriate ABORT error code, I am
not convinced that including [additional] invalid IPv4
addresses (such as 0.0.0.0 or 255.255.255.255) should
abort the establishment of the association.  I'll assume
that there is a valid address somewhere, because the
chunk got here!

I'll pose this preliminary question:

(Q1) If an INIT or INIT ACK message contains a well-formed but
numerically unusable IPv4 address, should the association setup
be aborted?

The RFC mentions an extreme case of an INIT ACK chunk containing
1,000 IPv4 addresses.  It seems harsh (to me) to reject the
whole association if one of these addresses is not usable.

There are "clues" in the RFC that one might proceed anyway
(assuming at least one usable address).  This is mentioned
several times, including here:

RFC 4960 Section 5.1.2, 2nd IMPLEMENTATION NOTE, page 60.
   IMPLEMENTATION NOTE: If an SCTP endpoint that only supports
   either IPv4 or IPv6 receives IPv4 and IPv6 addresses in an
   INIT or INIT ACK chunk from its peer, it MUST use all the 
   addresses belonging to the supported address family.  The 
   other addresses MAY be ignored.  The endpoint SHOULD NOT 
   respond with any kind of error indication.

On your actual question, it seems to me that "Unresolvable 
Address" is intended for an incoming request to use an Address 
Type that is not supported ("unwilling or incapable") by the 
receiver. So you would use this error code if you didn't
support IPv4 addresses at all, for example.

I don't see a more appropriate error code, though. Perhaps
this is because the answer to my (Q1) above is "no".

Various IPv4 multicast addresses (224.0.0.0 - 239.255.255.255)
including link local addresses, similarly don't seem appropriate
for SCTP.  I would be inclined not to police every address at
the expense of the association.  I'd just discover during the 
association that it isn't "reachable".

With thanks, from Chris Benson.

On Wed, 8 Sep 2010, Padmalochan Moharana wrote:

>>  Date: Wed, 8 Sep 2010 12:55:06 +0530
>>  From: Padmalochan Moharana <[email-masked]>
>>  To: tsvwg <[email-masked]>
>>  Subject: Invalid IP in INIT/INITCAK message
>>  
>>  Hi All,

---

From: Randy Stewart <[email-masked]>
Date: Wed, 15 Sep 2010 13:58:03 -0700

Chris:

Even besides the point you make is another issue in several
drafts that have been lost to time (and probably should be resurrected).

It is completely possible for a peer to list an address that it
really has but is not really valid for you. I.e. address scoping.

If the peer incorrectly scopes its address and for example
sends a private address "10.1.1.1" with its init..

In such a case you probably don't want to destroy the assoc.. but  
instead
silently discard the address.

V6 Link local address are in this same category.. If the source address
is a link local.. fine you can use it since you can determine which link
it goes with.. But if the link local is listed... then the address,  
though
valid for the sender is un-useable by the receiver since the receiver  
will
not know which link it goes with.

R

-----
Randall Stewart
[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 16 Sep 2010 12:26:50 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Randy Stewart
> Sent: Wednesday, September 15, 2010 1:58 PM
> To: Chris Benson
> Cc: tsvwg
> Subject: Re: Invalid IP in INIT/INITCAK message
> 
> Chris:
> 

Let's say the SCTP server has two inerfaces -- one public-facing
with a public IPv4 address, and another is 10.1.1.254.

How is the incoming SCTP INIT to the public IPv4 address, containing
10.1.1.1 in the INIT, supposed to be handled?  

Seems the SCTP client and server should try to use 10.1.1.1 and 
10.1.1.254 (when they are on the same network) but it's also 
important to not abort their association if they aren't on 
the same network (and there is another SCTP host on the 
local network, listening on the same port).

> not know which link it goes with.

Agreed that is a problem for link local (fe80::/64).

What of ULA (fc00::/7), which seem they could suffer the same scoping
problem as RFC1918 addresses -- namely, can't tell if the peer is
in the same scoped network or not.

-d

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 16 Sep 2010 21:58:09 +0200

> 10.1.1.1 in the INIT, supposed to be handled?  
Hi Dan,

we need to bring back the address scoping IDs... There was actually
one for IPv4 see
http://tools.ietf.org/html/draft-stewart-tsvwg-sctp-ipv4-00
and one for IPv6
http://tools.ietf.org/html/draft-stewart-tsvwg-sctpipv6-00

They need to be combined based on the so called level
from the first ID...

The client should not list the private address in the INIT,
when it is sent to a public address.
This is described by the second bullet of section 3.3 of the
above ID. The FreeBSD implementation would not list the address.

> local network, listening on the same port).
I think they should NOT list the addresses. If they want to use it,
the client should send the INIT to the private address listing
the global one.

Best regards
Michael

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 16 Sep 2010 13:11:33 -0700

> From: Michael Tüxen [mailto:[email-masked]]
> Sent: Thursday, September 16, 2010 12:58 PM
> To: Dan Wing
> Cc: 'Randy Stewart'; 'Chris Benson'; 'tsvwg'

But how do we prevent the association from being ABORTed,
as described in
http://tools.ietf.org/html/draft-stewart-tsvwg-sctp-ipv4-00#section-3.2

Seems in addition to what is described in that I-D, some ABORTs will 
need to be ignored.

> the client should send the INIT to the private address listing

The client cannot always know the server also has a private address.  
If it could, all of the server's addresses would be in DNS and 
we wouldn't need to have the addresses in INIT / INIT-ACK.

-d

---

From: Randy Stewart <[email-masked]>
Date: Thu, 16 Sep 2010 15:11:07 -0700

Dan:

SOme comments in-line..

> Seems in addition to what is described in that I-D, some ABORTs will

Well actually if the client outside follows the scoping draft as Michael
said you would NOT list the 10. network and thus no abort would be
generated.

And if you want to use the 10. network in the association then you would
need to have the client send the INIT to the 10. network to begin with.

This is the only way that the server would then know its safe to list
the 10. network and that the clients 10. network is reachable and the  
same
one as the servers...

The heart of the idea is to only list address that are in scope of
the association. If an address is not in scope then the client does
not list it... thus no aborts...

This is the same sort of thing that we do with link-local address in  
V6... the
only way you can add one to an association is NOT list it and send to  
your peer
(somehow the client must know which interface... KAME-BSD did this  
interface
index thing in the destination address)... and that way when you  
received the
packet you would include the link local address and be able to snatch  
in what
the actual input interface was....

You have the same problem there... since a link local on one network  
may be on another
at a different host...

If you follow the rules of those two drafts (which do need to be  
merged and resurrected) then
you would never have any stray aborts floating around..

R

>>>>>>> What should be the behavior of the SCTP endpoint on receive  
>>>>>>> INIT/
>>>>>>> INIT

-----
Randall Stewart
[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 16 Sep 2010 17:13:39 -0700

> From: Randy Stewart [mailto:[email-masked]]
> Sent: Thursday, September 16, 2010 3:11 PM
> To: Dan Wing
> Cc: "'Michael Tüxen'"; 'tsvwg'

I now see what you're saying, thanks.  

But this turns this into the same address-selection problem that is causing
us grief as described in RFC5220, RFC5221, and
draft-troan-multihoming-without-nat66.

-d

> >>>> is a link local.. fine you can use it since you can determine
> which
> >>>> link