RE: Invalid IP in INIT/INITCAK message

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

> -----Original Message-----
> From: Randy Stewart [mailto:[e-mail]]
> Sent: Thursday, September 16, 2010 3:11 PM
> To: Dan Wing
> Cc: "'Michael Tüxen'"; 'tsvwg'
> Subject: Re: Invalid IP in INIT/INITCAK message
> 
> Dan:
> 
> SOme comments in-line..
> 
> 
> On Sep 16, 2010, at 1:11 PM, Dan Wing wrote:
> 
> >> -----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.
> 
> 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..

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


> R
> 
> 
> >
> >
> >>> 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]
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >
> >
> 
> -----
> Randall Stewart
> [e-mail]
> 
>