[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thomas Narten's DISCUSS vote
Unfortunately, we had a little bureacratic mess-up. Thomas Narten, one
of the Internet AD's, sent in his formal DISCUSS vote late (Friday
night). Jeff had already fowarded me an earlier message which we
thought outlined all of Thomas's objections, and then Narten's formal
DISCUSS vote never was forwarded on to me (or to anyone else on the
working group), until this week. Grump, grump, grump, grump, grump.
A few of the items will likely require making a few changes to a number
of the documents, and I apologize to the working group editors for
having to make yet more round of changes. They should fortunately be
quite limited, as we are not open to making any other changes to these
drafts at this time.
I've made an initial overview through his objections, and have made some
comments below.
Could the document editors for the Arch-SEC, AH, ESP, DOI, ISAKMP, and
IKE please look at his objections and make corrections please? Aside
from those places where I've pointed text that Narten had missed, I
think most of his proposed complaints are reasonable ones to make. The
only one which may be somewhat contentions is the TTL sequence number
decrementing, but I advised Charlie to take this issue to the IESG two
weeks ago, so hopefully if there is going to be any clarification from
the Routing gods, we'll hear from them soon. If someone thinks one of
Thomas's objections should NOT be handled in the obvious way, please let
us know of your objections immediately, so that we not add any further
delay to the process.
Again, I beg the working group's indulgence for this last minute set of
objections that we didn't have a chance to deal with; hopefully we can
satisfy the IESG members and get these darned documents published once
and for all!
- Ted
>From: Thomas Narten <narten@hygro.raleigh.ibm.com>
>To: iesg@ietf.org
>Date: Fri, 24 Apr 1998 17:55:25 -0400
>Subject: Re: Ballot: Security Architecture for the Internet Protocol to Proposed Standard
>
>Apologies for the delay.
>
> Yes No-Objection Discuss * Abstain
>Thomas Narten [ ] [ ] [X ] [ ]
>
>> o Security Architecture for the Internet Protocol [PROPOSED]
>> <draft-ietf-ipsec-arch-sec-04.txt>
>
>page 7, paragraph on IPPCP should be updated. Work is done, there are
>drafts/RFCs to reference. WG will be shut down as soon as IPSec
>documents are out.
This is an RFC editor function. The RFC number (to our knowledge) has
not been assigned yet.
>Text relating to decrementing TTL of inner header of encapsulated
>packet needs clarification. Text should be clarified to say TTL
>decremented only if packet was forwarded (i.e., the forwarding
>operation is what decrements the TTL, not the fact that a complete IP
>packet is being encapsulated again upon entry to an IPSec tunnel). If
>packet originates from node, TTL is left unchanged. This is consistent
>with the current general practice of when to decrement TTLs, and some
>aspects of IPv6 protocols (i.e, ND) depend on it.
My understanding is that everyone is implementing this anyway. Thomas
in a later message suggested the following clarification, to be added
after the text which described when the TTL in the inner header should
be decremented:
Note: The decrementing of the TTL is one of the usual
actions that takes place when forwarding a packet. Packets
originating from the same node as the encapsulator do not
have their TTLs decremented, as the sending node is
originating the packet rather than forwarding it.
Charile Lynn has sent mail dissenting, claiming that it would be a bad
thing to do this since it would imply that this would imply that IPSEC
tunnels change the Internet Routing Topology, and if so, they might have
to conform to all requirements for Internet Routers. (I don't think
that's the case today for normal IP-IP tunnels, is it?)
Not clear what's the best way to resolve it. If Charlie is right that
this has some bad architectural implications, can we please get some
Internet Routing experts to explain to us exactly what the problem is
please? (and quickly).
If my sense that everyone is implementing it the way Thomas and what
apparently what most of the IPV6 working group wants, then we might as
well document that in the spec. My instincts are to document what
people are actually implementing and shipping as products, and if it's a
problem we can fix it later. This is *only* a proposed standard folks
---- we don't have to wait until it is perfect (and the technology
obsolete) before we ship it.
>> o PMTU message with >64 bits of IPsec header -- If the ICMP message
>> contains more information from the original packet, e.g., the 576
>> byte minimum for IPv6, then there MAY be enough non-opaque
>> information to immediately determine to which host to propagate the
>> ICMP/PMTU message and to provide that system with the 5 fields
>> (source address, destination address, source port, destination
>> port, transport protocol) needed to determine where to store/update
>> the PMTU. Under such circumstances, a security gateway MUST
>> generate an ICMP PMTU message immediately upon receipt of an ICMP
>> PMTU from further down the path.
>
>reference to 576 byte MTU in IPv6 should be dropped (since it is
>incorrect per the latest drafts). Reference is probably irrelevant to
>the point being made here anyway, so it can easily be removed (i.e.,
>no need to reference the value itself).
sure...
>
>> IP Authentication Header [PROPOSED]
>> <draft-ietf-ipsec-auth-header-05.txt>
>
>
>> As a new extension header or IPv4 option is created, it will be
>> defined in its own RFC and SHOULD include (in the Security
>> Considerations section) directions for how it should be handled when
>> calculating the AH ICV. If the IPsec implementation encounters an
>> extension header that it does not recognize, it MUST zero the whole
>> header except for the Next Header and Hdr Ext Len fields. The length
>> of the extension header MUST be computed by 8 * Hdr Ext Len value +
>> 8. If the IPsec implementation encounters an IPv4 option that it
>> does not recognize, it should zero the whole option, using the second
>> byte of the option as the length. (IPv6 options contain a flag
>> indicating mutability, which determines appropriate processing for
>> such options.)
>
>Text regarding processing of unknown extension options seems wrong
>(there are bits in header saying whether field is mutable). Sync up
>with IPv6 documents. Note: IPv6 document says "mutable" rather than
>"has predicatble value at receiver"
>
>Note: I've sent mail to IPng chairs seeking clarification.
This has been dealt with.
>> 3.3.2 Sequence Number Generation
>>
>> The sender's counter is initialized to 0 when an SA is established.
>> The sender increments the Sequence Number for this SA and inserts the
>> new value into the Sequence Number Field. Thus the first packet sent
>> using a given SA will have a Sequence Number of 1.
>>
>> If anti-replay is enabled (the default), the sender checks to ensure
>> that the counter has not cycled before inserting the new value in the
>> Sequence Number field. In other words, the sender MUST not send a
>> packet on an SA if doing so would cause the Sequence Number to cycle.
>> An attempt to transmit a packet that would result in Sequence Number
>> overflow is an auditable event. (Note that this approach to Sequence
>> Number management does not require use of modular arithmetic.)
>>
>> If anti-replay has been disabled, the sender does not need to monitor
>> or reset the counter, e.g., in the case of manual key management.
>
>Clarify last sentence. Is sender *always* required to increment
>sequence number? Or does disable mean always sends the same one (which
>may cause interoperability problems with receivers)?
>
>I would guess that the intent is that you always increment, and the
>anti-replay simply disables the deletion of the SA when the sequence
>number cycles back to 0. Once the replay counter reaches its max
>value, it "sticks". Or does the counter simply contain a random value?
>I just can't quite tell from the text.
>
>Another way of clarifying this to me is if there was clear text that
>says: anti-replay should be enabled only if the sender has specific
>knowledge that the receiver ignores the replay counter (i.e., the
>information has been negotiated via ISAKMP or manual configuration).
I thought this was pretty obvious to all implementors. If anti-reply has
been disable, the sequence number still increments, and when you reach
the max value, it rolls over to back to zero. Perhaps the use of the
vernacular "cycles" is the problem here. The text in the last paragraph
pretty clear that in the absense of anti-reply, you just always let the
sequence number roll over (and the text in the first paragrph indicates
that you always increment).
I suppose we can make this even more explicit, since if the Internet AD
thought it ambiguous, there's a good chance other folks might also get
confused.
>
>> 3.4.3 Sequence Number Verification
>
>> If the receiver does not enable anti-replay for an SA, no inbound
>> checks are performed on the Sequence Number. The default for the
>> sender is that the Sequence Number will be checked at the sender.
>> Hence, if an SA establishment protocol such as ISAKMP/Oakley is
>> employed, the receiver SHOULD notify the sender, during SA
>> establishment, if the receiver will not provide anti-replay
>> protection.
>
>Why SHOULD? what action can the sender take? (this is related to the
>above question, no doubt.)
The idea here is that the sender should know what security services are
being provided (and possibly stop sending if the security services being
provided are not to its liking).
>
>> 5. Conformance Requirements
>>
>> Implementations that claim conformance or compliance with this
>> specification MUST fully implement the AH syntax and processing
>> described here and MUST comply with all requirements of the Security
>> Architecture document. If the key used to compute an ICV is manually
>> distributed, correct provision of the anti-replay service would
>> require correct maintenance of the counter state at the sender, until
>> the key is replaced, and there likely would be no automated recovery
>> provision if counter overflow were imminent. Thus a compliant
>> implementation SHOULD NOT provide this service in conjunction with
>> SAs that are manually keyed.
>
>Don't understand above, probably related to my confusion regarding
>what is required for sequence counters.
The "counter overflow" is referring to the fact that the sequence number
rolls over when you increment a 32-bit value with all bits set by one.
>
>
>> IP Encapsulating Security Payload (ESP) [PROPOSED]
>> <draft-ietf-ipsec-esp-v2-04.txt>
>
>Sequence number stuff. If text in AH gets changed (per above) change
>should be made here as well.
I think it's clear enough, but sure, we can add the same clarifying text
to both the AH and ESP documents.....
>
>> The Internet IP Security Domain of Interpretation for
>> ISAKMP [PROPOSED]
>> <draft-ietf-ipsec-ipsec-doi-08.txt>
>>
>
>> 4.4.1.4 PROTO_IPCOMP
>>
>> The PROTO_IPCOMP type specifies IP payload compression.
>
>Add explicit reference to draft-ietf-ippcp-protocol-05.txt
>
>> 4.4.4.4 ESP_RC5
>>
>> The ESP_RC5 type specifies the RC5 transform defined in [ESPCBC].
>>
>> 4.4.4.5 ESP_IDEA
>>
>> The ESP_IDEA type specifies the IDEA transform defined in [ESPCBC].
>>
>> 4.4.4.6 ESP_CAST
>>
>> The ESP_CAST type specifies the CAST transform defined in [ESPCBC].
>>
>> 4.4.4.7 ESP_BLOWFISH
>>
>> The ESP_BLOWFISH type specifies the BLOWFISH transform defined in
>> [ESPCBC].
>
>Are the above required or MAY? (I assume they are optional, adding a
>sentence to that effect would be good and consistent.)
All algorithsm which are required have MUST's. Can we simply put a
blanket statement at the beginning of the session saying that all items
which do not explicitly state "MUST implement" are optional?
>
>> 4.4.5.2 IPCOMP_DEFLATE
>>
>> The IPCOMP_DEFLATE type specifies the use of the "zlib" deflate
>> algorithm.
>
>Add reference to draft-ietf-ippcp-deflate-03.txt (draft approved by IESG
>for publication).
>
>>
>> 4.4.5.3 IPCOMP_LZS
>>
>> The IPCOMP_LZS type specifies the use of the Stac Electronics LZS
>> algorithm.
>
>Add reference to draft-ietf-ippcp-lzs-04.txt (draft approved by IESG
>for publication).
>
>> 4.4.5.4 IPCOMP_V42BIS
>>
>> The IPCOMP_V42BIS type specifies the use of V42bis compression.
>
>Delete this section/definition (and all references to V42bis) per
>conversation with Naganand Doraswamy (IPPCP WG Chair). No document
>exists or is expected.
Sure...
>
>Section 6.6: resolve inconsistency between IPPCP document and this
>one.
This has been dealt with.
>
>> Internet Security Association and Key Management Protocol
>> (ISAKMP) [PROPOSED]
>> <draft-ietf-ipsec-isakmp-09.txt>
>
>references to RFC 1825 need to be updated. I assume that 1825 will be
>obsoleted?
Yes, references to RFC-1825 should be updated to whatever the RFC of the
newly assigned arch-sec document. Doug, you should change this to state
draft-ietf-ipsec-sec-arch-xx.txt for now...., to make sure the RFC
editor catches these.
>
>> When transmitting an ISAKMP message, the transmitting entity (initiator or
>> responder) MUST do the following:
>>
>>
>> 1. Set a timer and initialize a retry counter.
>
>Leave timer value, and retransmission issues completely to
>implementation? Is this good for Internet? Perhaps add text along the
>lines:
>
>Implementations MUST NOT use a fixed timer. Instead, retransmission
>timer values should be adjusted dynamically based on measured round
>trip times. In addition, successive retransmissions of the same packet
>should be separated by increasingly longer time intervals (e.g.,
>exponential backoff).
Yes, that seems fair criticism. We should make this change.
>
>> 3. Check the Major and Minor Version fields to confirm they are correct.
>> If the Version field validation fails, the message is discarded and
>> the following actions are taken:
>
>Clarify what check is required. If minor numbers don't match, reject?
>Accept same major, but lower minor? (or did I miss the text on this
>point?)
You missed text on this point. See section 3.1, ISAKMP Header Format,
where it states:
o Major Version (4 bits) - indicates the major version of the ISAKMP
protocol in use. Implementations based on this version of the ISAKMP
Internet-Draft MUST set the Major Version to 1. Implementations
based on previous versions of ISAKMP Internet-Drafts MUST set the
Major Version to 0. Implementations SHOULD never accept packets with
a major version number larger than its own.
o Minor Version (4 bits) - indicates the minor version of the ISAKMP
protocol in use. Implementations based on this version of the ISAKMP
Internet-Draft MUST set the Minor Version to 0. Implementations
based on previous versions of ISAKMP Internet-Drafts MUST set the
Minor Version to 1. Implementations SHOULD never accept packets with
a minor version number larger than its own, given the major version
numbers are identical.
>> The Internet Key Exchange (IKE) [PROPOSED]
>> <draft-ietf-ipsec-isakmp-oakley-07.txt>
>
>> IKE implementations MUST support the following attribute values:
>>
>> - DES-CBC with a weak, and semi-weak, key check (weak and semi-
>> weak keys are referenced in [Sch96] and listed in Appendix A). The
>> key is derived according to Appendix B.
>>
>> - MD5 and SHA.
>>
>> - Authentication via pre-shared keys. The Digital Signature
>> Standard SHOULD be supported; RSA-- both signatures and
>> authentication with public key encryption-- SHOULD be supported.
>>
>> - MODP over the default group (see below). ECP and EC2N groups MAY
>> be supported.
>>
>
>Clarify MUST/SHOULD for authentication. What part is the SHOULD, what
>part is the MUST? (Or am I confused?)
I thought it was straightforward. All are MUST's, except for those
things listed which are explicitly should's. We can word it more like a
legal document to make sure there's no chance anyone could possibly get
confused on that point.
>
>Need reference to PKCS #1 (normative).
>
>Appendix A:
>
>add explicit references to documents in places where well known
>numbers are "defined", for example:
>
> - Encryption Algorithm
> DES-CBC 1
> IDEA-CBC 2
> Blowfish-CBC 3
> RC5-R16-B64-CBC 4
> 3DES-CBC 5
> CAST-CBC 6
>
>This should be done in several places.
Sure..... I don't personally think this was worth holding up documents
at the PROPOSED STANDARD level, but while we're making changes, we can
add the references.
>
>> The NULL Encryption Algorithm and Its Use With IPsec [PROPOSED]
>> <draft-ietf-ipsec-ciph-null-00.txt>
>
>
>> The IPsec Authentication Header [AH] specification provides a similar
>> service, by computing authentication data which covers the data
>> portion of a packet as well as the immutable in transit portions of
>> the IP header. ESP_NULL does not include the IP header in
>> calculating the authentication data. This can be useful in providing
>> IPsec services through Network Address Translation (NAT) devices and
>> non-IP network devices. The discussion on how ESP_NULL might be
>> used with NAT and non-IP network devices is outside the scope of this
>> document.
>
>Comment about NAT seems very questionable, since all useful protocols
>that run on IP (i.e. TCP/UDP) have a pseudo-header that depends on the
>addresses. I suspect the authors were thinking that with the payload
>in the clear, NAT could update the checksum. However, the AH check
>will not allow that. Suggest removing text.
The text is valid; ESP includes integrity protection, although ESP
doesn't cover the IP header. In the new IPSEC scheme, it is extremely
unlikely that someone will use both ESP and AH. ESP-NULL provides no
data confidentiality, but it does provide integrity over the packet data
(but not of the IP headers), thus allowing NAT boxes to muck with the IP
headers.
Whether or not this is a horrible abstraction violation is besides the
point; if the goal is to allow NAT boxes to work, while still providing
data integrity services for the packet contents, ESP NULL is one way of
accomplishing that goal.
- Ted
Follow-Ups: