RE: Invalid IP in INIT/INITCAK message

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Michael Tüxen [mailto:[e-mail]]
> Sent: Thursday, September 16, 2010 12:58 PM
> To: Dan Wing
> Cc: 'Randy Stewart'; 'Chris Benson'; 'tsvwg'
> Subject: Re: Invalid IP in INIT/INITCAK message
> 
> On Sep 16, 2010, at 9:26 PM, Dan Wing wrote:
> 
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] 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:
> >>
> >> 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..
> >
> > 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?
> 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.

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.


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

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

> Best regards
> Michael
> >
> >> 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.
> >
> > 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
> >
> >
> >> R
> >>
> >> On Sep 14, 2010, at 11:48 AM, Chris Benson wrote:
> >>
> >>> 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 <[e-mail]>
> >>>>> To: tsvwg <[e-mail]>
> >>>>> Subject: Invalid IP in INIT/INITCAK message
> >>>>>
> >>>>> 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
> >>>>>
> >>>
> >>
> >> -----
> >> Randall Stewart
> >> [e-mail]
> >>
> >>
> >
> >
> >