Re: A comment about MAST

[Dave Crocker <dhc@dcrocker.net>]

Eugene,

thank you for the comments.

EMK> completely hidden from upper-level applications so they will still
EMK> identify the connection as between IP.a, Port.l, and IP.y, Port.r
EMK> (communication endpoints).  Although this is the least intrusive
EMK> approach, I think this is not enough if applications that `leak' those
EMK> endpoints over the wire were to benefit from MAST.  This is somewhat
EMK> similar to the classic NAT problem.

I think it is exactly the same, yes.


EMK> My suggestion is to expose the address changes to upper-level
EMK> applications through some backward-compatible API extension, which shall
EMK> notify applications that addresses are being added to or removed from
EMK> the local or remote endpoint identifier.

More generally, you are suggesting a line of consideration that the draft
probably should mention.  Namely, it might discuss additional areas for
development.  There is already a small amount of such commentary in the
document. The suggestion you are making is an interesting one for this.  Some
sort of "roadmap" would probably be helpful.

In general, IETF protocol work does not specify APIs, though of course there
are exceptions.  Certainly it would be useful to suggest this separate
information channel to the application.


EMK>   Complex applications (and
EMK> protocols they implement) that do care about and use endpoint
EMK> identifiers over the wire can be modified to utilize MAST and this new
EMK> API so they can propagate address changes accordingly.  If they ignore
EMK> the new API, their operation will break at the moment an original
EMK> endpoint address, local or remote, becomes invalid; but since they will
EMK> break anyway without MAST at all at that moment, this seems to be a
EMK> non-issue.

Right.  And a good discussion worth adding to the proposal is about
application awareness of current addresses.


EMK> I am not suggesting that the MAST proposal should define such APIs with
EMK> it; IMO they are better left out as future work items as individual
EMK> operating systems implement MAST.

Yes, but I do think the proposal will benefit from having some discussion
about the issue.  Thank you for raising it.


EMK> P.S. Which is the main discussion list for MAST, and could you forward
EMK> this to the list if there is one?

multi6.  I have forwarded your note, and copied you.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>