[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on latest IPSP drafts


I haven't been commenting hardly at all so I won't be suprised if my
comments at this late date don't have much effect.  Still, I thought
I'd toss them in.  (Mark: hope you don't mind if I use parts of your
message as a framework)

From:  Mark H Linehan/Watson/IBM Research
        <linehan@watson.ibm.com>
To:  ipsec <ipsec@ans.net>

}...
}
}- I suggest that there should be a discussion of the impact of IP
}fragmentation.  In particular: (a) performance is affected since IP packets
}that already equal the MTU size will overflow with the addition of the AH or
}ESP data; (b) I think there should be an implementation note that the sender of
}an IPSP packet should make sure to put it through the fragmentation process,
}and the destination of an IPSP packet must reassemble it before processing the
}AH header or ESP payload.

I actually think that any mature encryption standard has to include
compression.  It's one of the clear superiorities of PGP over PEM.  But
I recognize that most people consider it some sort of patent quirmire.
Still, I hope the next generation of transformations include compression.

}- The definition of "authentication" and "integrity" on page 1 of the
}architecture draft implies that the former is a superset of the latter.  This
}is inconsistent with the usual terminology, which treats these as distinct
}concepts.

But isn't the usual terminology wrong in this regard?  How can you
determine that a message is authentic if you can't tell that it has
been changed (don't have integrity)?

}...
}
}- Page 12 of the architecture document and various other places require
}user-oriented keying. It's not at all clear what that means for (a) systems
}that don't have userids (e.g. Windows); (b) services that operate on behalf of
}multiple users (e.g. nfsd); (c) systems that forward data between interfaces.
}I think (c) is supposed to be excluded by the words "... traffic originating at
}that system," but those words are not repeated in the several places that
}require user-oriented keying. At the least, I think there should be some text
}discussing these issues.
}
}In general, the network layer does not logically have access to user-related
}information, and some implementations may find it difficult or impossible to
}fulfill this requirement.  I suggest that IPSP should not (a) force
}implementations to violate the usual separation between network layers by
}requiring the IP layer to know the relationship between packets and users; and
}(b) should not rule out implementations that simply can't meet this requirement.

Maybe the wording need to be cleared up and maybe there are dedicated
systems where this doesn't apply but the ability to use different keys
on different conversations is essential.  In general, the IETF
concentrates on the bits on the wire while giving freedom for
different arrangements within "operating systems" and the like.
"Levels" a la OSI may be a useful model in some cases but they should
be an aid to design, not a straight jacket.  Some conversations, like
NTP or routing, may be host level and servered apropriately by host
level keys.  But IPSEC will not have done its job if it can't stop the
endless stream of end to end interactive application level security
protocols (telnet, ftp, etc., etc.).  (Note: this remark does not
apply for store and forward services such as Mail, DNS, and HTTP which
can not be adequately served by a simple "connection" oriented
security protocol.)  It should be possible on multi-user systems for
the keying to authenticate different users and processes, even if this
is just done in some cases by letting an application do the work
itself.

Seems to me that a "Windows" system should have separate keys for
different services it might offer so that if host A had several
logical connections up with Windows machine B, one for ftp, one for a
telnet session, one for news transfer, etc., they would be separately
keyed.

Really, as long as a system is set up so there can be different keys,
they most of the complexity here is at the session keying level, not
in the packet formats.

}...
}
}- There has been a lot of discussion about whether the DES-CBC transport should
}be required.  I respectfully submit that there is a set of organizations and
}individuals who MUST (in a much more significant sense of "MUST") obey U.S.
}(and other nation's) laws and who will require an engineering solution to
}provide exportable encryption.  Either this engineering group can provide that
}solution or someone will have to define an IPSECbis and an IPv6bis.  The risk
}is fragmentation of standards.  Since the set of people affected by the export
}laws is large, I argue that this working group should address the issue.

There are also lots of people that need to communicate securely within
the United States and lots of people outside the United States
unaffected by the US export laws who need to communicate securely.  If
someone want to define an insecure procotol that is freely exportable
from the US, they certainly can but I would recommend that anyone who
wants to communicate securly not use such an insecure protocol. It
would certainly be a bad idea for the IETF to endorse such an insecure
protocol as providing people with security.  In fact, my understanding
of the current situtaion is that, while individual export approval is
required, it is easy to get permission to export DES-CBC
confidentiality from the US to any US company including any US
subsidiary abroad unless it is in one of a few countries that are
specially restricated.

People who want security need to use strong algorithms.  I can't see
why adopting a strong algorithm would cause anyone any difficult in
secure communications.  If they need the protocol implemented some
place to which it can not be exported from the US, they will be
trivially able to get it from elsewhere.

All levels of the IETF has considered this problem and the strong
consensus in the IPng working group, the IESG, the IETF plenary, etc.,
etc., has consistently been that the IETF standard should require
strong security.

}...

Donald
References: