[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thomas Narten's DISCUSS vote
> >> 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.
I should have been more clear. The current paragraph says:
The IPsec DOI supports negotiation of IP compression, motivated in
part by the observation that when encryption is employed within
IPsec, it prevents effective compression by lower protocol layers.
The IETF working group, "IP Payload Compression Protocol (ippcp)" has
the charter to "develop protocol specifications that make it possible
to perform lossless compression on individual payloads before the
payload is processed by a protocol that encrypts it. These
specifications will allow for compression operations to be performed
prior to the encryption of a payload by such protocols as IPsec."
It doesn't reference any document (i.e., the RFC editor won't see
this). The point I meant to make was that although the WG is
technically still in existance, it has actually completed its work
(which can be cited) and will go away once the IPSec documents are
out. So the text could be updated. (This is a minor point, but thought
it would be worth updating if the TTL decrementing text is also to be
updated.)
> >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.
I think it's important to get this specified right the first time for
the IPv6 case. There are scenarios in IPv6 where decrementing the TTL
incorrectly will prevent ND from operating correctly over tunneled
links. Better to nip this one in the bud.
> >> 3.3.2 Sequence Number Generation
> 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.
Since I don't think there is really an interoperability issue here,
regardless of what the sender implements when anti-replay is enabled
(i.e,. the receiver doesn't care), leaving the text alone would be not
be a big deal. However, assuming the document is going to be cycled
anyway for the TTL stuff, how about just adding something like the
following:
On the sending side, the only difference in behavior for the cases
where anti-replay is enabled or disabled is that in the latter case,
when the sequence number wraps back to 0, transmission continues using
the same SA. When anti-replay is enabled, the sequence number is not
permitted to wrap; at the point when the sequence counter is about to
wrap back to 0, no more packets may be sent out using that SA.
> >> 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?
That would be fine. I just seemed inconsistent to not say MAY here,
since all the other transform-specfic definitions where
explicit. (Also, this change is certainly not a show stopper, but
seemed worth making given the need for changes related to IPPCP.)
> >> Internet Security Association and Key Management Protocol
> >> (ISAKMP) [PROPOSED]
> >> <draft-ietf-ipsec-isakmp-09.txt>
> >
> >> 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.
Yep! Thanks.
> >> 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.
I read it as saying authentication via pre-shared keys is
required. But then the text lists specific algorithms that SHOULD (not
MUST) be supported. I suppose there is an assumption that one can use
other mandatory transforms. The question I had in my mind was whether
something was required in the MUST sense, but that the SHOULDs could
lead to different implementations not interoperating because they
didn't implement a common transform. Given that there are mandatory
transforms, this shouldn't be an issue.
> >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.
Actually, the references are pretty important. There will most
certainly be interoperability issues if there is confusion about which
RFCs correspond to which transform numbers.
Thomas
References: