RE: shim - transport/app communication

["Bound, Jim" <jim.bound@hp.com>]

> Bound, Jim wrote:
> 
> > Yes and what must be on the wire are valid IP addresses in 
> the header.  As
> > we don't know what these will look like and how they are to 
> be managed it is
> > uclear and not your shim spec draft-ietf-multi6-l3shim-00.txt.
> 
> Nobody has proposed changing the IP addresses that are seen 
> on the wire. 
> All we are changing is to add a dynamic mapping between what IP 
> addresses the transport and above sees (the ULIDs) and the IP 
> addresses 
> the routing system sees.

That is not crystal clear to me in the spec above at all.

> 
> >  Add network
> > management to that etc.  The point is that multihoming 
> architecture should
> > solve that specific set of problems not cause any change to 
> the rest of the
> > network operational infrastructure.  That is why I still 
> believe SCTP is the
> > correct approach by adding ULID extensions, we are 
> reinventing the wheel.
> > The engineering cost and time to market for implementation 
> will be faster if
> > we use SCTP and build TCP shims for multihoming. 
> 
> You mean carry TCP (and UDP?) over SCTP, or something different?

Something different.  Map an TCP request to an SCTP request as if the
transport selected was SCTP.

> 
> > And we can meet a
> > reasonable time to market product set introduction.  The 
> ULID for the wire
> > should be carried as a DST Option. 
> 
> I'd like to understand why you think a DST option in every packet is 
> necessary. Such a thing would be complete untrusted.

Yes the trust would be a problem.  Could be reference to look for ULID
new extension header then which could be encrypted with IPsec then.  The
reason to pass the ULIDs is to save processing on each node for mapping
to them at the transport and above.  This shim now will require a search
for ULID on every packet. Providing the ULID in the packet avoids that
on every system?

> Thus it would be 
> better if middleboxes that want to do verification either
>   - get explicitly signaled from the endpoints so that they 
> have the list
>     of IP addresses
>   - observe the sim6 signaling protocol and do the same 
> verification as
>     the endpoints do as a way to discover the list of IP addresses
> Both of those can be reasonably secure.

Yes that is possible but was trying to avoid this and keep e2e only and
as needed also if they change that can be accomodated too.

> 
> > I will wait for your next spec to comment
> > on how this can be done and slight changes to some of the 
> diagrams in the
> > spec.  But figure your putting out a new spec soon on that 
> now, if not I can
> > send you offline comments.  This effort should not impact 
> the rest of the
> > Internet network implementations or it will never happen. 
> 
> I agree it shouldn't impact the rest of the Internet.
> 
> 
> > Yes you discuss this in the draft above and left it that 
> this may have other
> > problems.  I agree. But to my point above the multihoming 
> solution should
> > not have to cause "signaling protocols" to change.  That is 
> my concern and
> > most of my concerns are take care of if the src and dst 
> addresses are IPv6
> > addresses and only them in the header when entering the wire.
> 
> I don't think "signaling protocols" need to change more than 
> they need 
> to change to support SCTP (and in both cases this might be a host 
> implementation issue and not a protocol standard issue).
> Suppose that one is using RSVP to setup reservations for some 
> IP address 
> pair and port number pair. If the IP addresses change, whether it is 
> SCTP or the shim that does such a change, you'd want to do something 
> with the RSVP reservation (either change it to include all 
> the addresses 
> that are used, or change it to use the new addresses).

Forget my comment I wanted to be sure IP addresses were being used.  

> 
> So I think this level of change is inherest in the problem of 
> wanting to 
> switch the IP addresses to have the communication survive, and 
> indepedent of the layer in the stack where we add the address agility.

I agree as long as the wire is IPv6 address format compliant etc.

thanks
/jim

> 
>     Erik
>