Re: a draft that missed the deadline

[Sandy Murphy <[e-mail]>]

>I was quite disappointed to see no mention of
>draft-heffernan-tcp-md5-02.txt.gz (admittedly, it has expired) or its
>methods.  You alude to the benefits, but seem completely oblivious to the
>fact that it's already in shipping code.

I am well aware of Andy Heffernan's work (which I thought you also had
a hand in, judging by our conversations about TCP RST's).  I did not
mention it because, as you said, the work had been dropped from the
IETF working group active consideration.  I thought that the reason
those drafts were allowed to expire was because the protection
provided by IPSEC is at least as good as the protection provided by
doing MD5 protection at the TCP level.  Given the limited amount of
option space in the TCP packet and the recent concerns about MD5
potential vulnerabilities by itself (leading the IPSEC group to
recommend the HMAC approach), the IPSEC solution might even be better.

Be that as it may, I saw several messages in September between Ran
Atkinson and Jeff Schiller about that draft, suggesting that it might
be resurrected for publication as an Informational RFC.  Do you know
anything more about that?

On a side note, I've been trying to come up with good reasons why
keyed crypto hash protection at the application level might still be
useful when IPSEC is fully deployed.  Given the number of protocols
that have defined their own protection while waiting for IPSEC, it is
a question with some broad applicability.  One might say that
protecting at the application level prevents other processes in the
same host from horning in.  Can you see that as a valid concern to
keep application level protection when IPSEC protection is available?

>I was also hoping for more of a recommendation for the internal sources
>solution.  The problem there is of the most theoretical interest and the
>one that we would appreciate the assistance on.

I was asked, not for a recommendation, but for a discussion of the
possibilities and the costs.  I think that the business environment
plays such a large part in determining what level of protection you
need as well as how much you're willing to do to protect yourself
that it may take a community decision to make a recommendation.

If the usual environment was such that a valid sequence of BGP peers
was almost certainly also a valid AS_PATH (i.e., the policy decisions
would let traffic through), then Brad Smith's proposal to insert link
state information is attractive.  The frequency of signatures (I think)
can be reduced and therefore the number of verifications. You do have
to check each AS_PATH against the link state information to see if it
is a valid sequence of adjacent AS's, though.

If the usual environment was such that valid sequences of BGP peers
were NOT likely to be valid AS_PATH (because of peering agreements
and their effect on the traffic that will be transited, etc.), then
you need assurance that the *path* is valid, which can mean assurance
that your neighbor came by the determination of the path he/she/it
sent you honestly - which means some sort of proof that your neighbor
based its path on information IT received from a neighbor - which
means passing on to you some sort of token from the neighbor's neighbor.
And so forth.

As I said, the Internet registries can provide some of this assurance.
They certainly collect the sort of information that would provide
assurance that the hops represented in the AS_PATH are valid.  They
might also collect the detailed information about policies that would
help determine that AS_PATHs are valid.  The business environment
sticks its nose in that as well, as the policy information needed to
determine the validity of AS_PATH might be sensitive and something the
ISPs would not want published to the world.

>Finally, I was really hoping to see more discussion of the prefix
>assignment problem.  Again, you allude to it briefly in section 3.3, but
>the authenticated delegation of prefixes is a serious problem that we could
>use help with.

When you say "prefix assignment" problem, you're talking about some AS
announcing a prefix that actually belongs to someone else? especially
when it's in the middle of someone else's CIDR block?  Unfortunately,
asking for that sort of protection is asking for assurance that
someone is *authorized* (not just authenticated) to speak the
information they are providing.

Authorization is always something that one is given by someone else.
So authorizing the advertisement of a network implies an
infrastructure for assigning networks to AS's.  That means, for
example, an authenticatable token from IANA proving you are allowed to
announce this network (maybe given to you when you acquire the
address), or some verification from some Internet registry (which
implies an infrastructure that would make sure the registry itself had
the correct info and got the info to you securely, etc).

This is more than just a protocol question.  Do you think the idr
group (and maybe the rps working group) could take on recommending an
infrastructure like this?  (I suppose you point to DNS as an example
of a working group that set up a ownership infrastructure.)

Then there's the problem of aggregation of information.  If you have
aggregated several pieces of properly authorized information, how do
you show that you are authorized to speak the aggregate?  Include all
the individual authorization tokens?  That would pretty much undo the
benefits of aggregation.

And de-aggregation is a problem as well.  As long as BGP contains
features to allow de-aggregation (a necessity, I think) of the
addresses received, there will be the possibility of mis-use.  I
actually came to a full stop in early May on this work when I realized
that the MAI-Sprint problem was a fully legal use of the protocol,
just an extremely unwise one.  Maybe the proof-of-originable-address
infrastructure could prevent AS's from announcing class-ful addresses
that they weren't directly connected to.  I think that would mean
the protocol would have to know when an address was being advertised
as a direct connection, different from the ORIGIN attribute. 

This message is long enough.  I'll quit for now.

--Sandy