Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt

From: <[email-masked]>
Date: Tue, 3 Feb 2004 14:12:07 +0200

Hi Marcelo,

You were quick.  A small preface before I get to your points.  I worked
with Lode to get this document done by Friday, it could stand some improvement.
Additionally, the SCTP multihoming document needs updating.  We can try to get
these both updated before Seoul.

Secondly, my general feeling is that SCTP is one tool for Multi6 - I am
not sure if it is the entire answer.  I think we need to discuss this.

Finally, there have been some interesting ideas on how to transition SCTP
on the ietf.org mailing list, I am not sure if they should/could be discussed in
this document. If so, I can try to capture some of them when we update the document.

Now onto your points:

> Just a couple of comments, IMHO one of the important benefits of using a
> transport layer mechanism to preserve established communications is that the
> security is simpler than the mechanisms at 3.5 layer. The reason for this is
> that only a connection is at stake, and not the complete identity of the
> host.  

I agree.  One of the interesting properties of SCTP is that it is possible to 
for connections to set the addresses to use from the host, for example, over 
all/any available interfaces & IP addresses.  Applications could use this, 
or could include just the IP addresses that they consider important for their
needs.

> This allows to build simple return routability checks which may be
> acceptable, while they are probably not acceptable for lower layer
> solutions. Perhaps a comment about this would fit in section 2.3.2 or in the
> section 3?

This I can include.  In a way, SCTP employs a return routable-like mechanism
in the initialization phase.

> Another comment is about how does an sctp solution deals with ingress
> filtering?

In what way do you mean?  SCTP has some resistence to DoS-style attacks,
like SYN floody, by way of its setup.  This won't solve everything, of couse,
I am sure that hackers will find other ways to cause mischief.

thanks,
John

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 3 Feb 2004 15:17:04 +0100

Hi John,

> these both updated before Seoul.

Thanks for providing this doc so fast. IMHO the SCTP POV is important.

> not sure if it is the entire answer.  I think we need to discuss this.

I agree with you, IMHO SCTP is just one of the tools that can be used to
preserve established communications in mh environments

> this document. If so, I can try to capture some of them when we

I don't know about the document, but i would find useful to understand how
easy is to migrate to sctp, this would have a great impact on the
deployability of the solution.

> in the initialization phase.

Ok, and this would be acceptable from a security POV becuase it only affect
this particular connection and not all the present and future connections of
this host

> I am sure that hackers will find other ways to cause mischief.

No, this is not a security issue, sorry if my writing was misleading. this
is a functional issue.
Please check section 3.3 of draft-huitema-multi6-hosts-02.txt for a detailed
explanation
Basically you have to make sure that the packets are not filtered by ingress
filters that is you have to make sure that the source address contained in
the packets is the correct one (or that the exit router through which the
packet is carried is the appropriate one)

Regards, marcelo

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 9 Feb 2004 21:00:10 +0100

> not sure if it is the entire answer.  I think we need to discuss this.

Having the proposals outline if they are enough as stand-alone or as 
complements or needs complements, should be an important part of the 
self-evaluation. Which of the alternatives are desired should be part 
of the architectural evaluation. And we need to get there...

> this document. If so, I can try to capture some of them when we update 

Transition is part of the questions in Eliots draft.

- - kurtis -