[IPsec] Config payload text in Section 4
Section 4 of IKEv2bis (and RFC 4306) states: IKEv2 is designed to permit minimal implementations that can interoperate with all compliant implementations. There are a series of optional features that can easily be ignored by a particular implementation if it does not support that feature. Those features include: o Ability to negotiate SAs through a NAT and tunnel the resulting ESP SA over UDP. o Ability to request (and respond to a request for) a temporary IP address on the remote end of a tunnel. A little further down Section 4 also states: Implementations are not required to support requesting temporary IP addresses or responding to such requests. Finally Section 4 also states: A minimal IPv4 responder implementation will ignore the contents of the CP payload except to determine that it includes an INTERNAL_IP4_ADDRESS attribute and will respond with the address and other related attributes regardless of whether the initiator requested them. A minimal IPv4 initiator will generate a CP payload containing only an INTERNAL_IP4_ADDRESS attribute and will parse the response ignoring attributes it does not know how to use. By reading all the text in Section 4 it is seems that "minimal IPv4 responder implementation" means an implementation that minimally supports responding to a config payload request and that "minimal IPv4 initiator" means an implementation that minimally supports requesting a temporary IP address. Unfortunately, the terms "minimal IPv4 responder implementation" and "minimal IPv4 initiator" alone are somewhat ambiguous and can be interpreted as contradiction to the first two statements I cited above. I suggest changing the text in the last two paragraphs I cited to: An implementation that minimally supports responding to a request for a temporary IP address will ignore the contents of the CP payload except to determine that it includes an INTERNAL_IP4_ADDRESS attribute and will respond with the address and other related attributes regardless of whether the initiator requested them. An implementation that minimally supports requesting a temporary IP address will generate a CP payload containing only an INTERNAL_IP4_ADDRESS attribute and will parse the response ignoring attributes it does not know how to use. Dave Wierbowski ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Traffic visibility - consensus call
At 3:02 PM +0530 1/11/10, Bhatia, Manav (Manav) wrote: Dan, You trust the end nodes to negotiate WESP and encapsulate their ESP packets in WESP but you don't trust the content they put into those packets. Is that the trust model you're operating on? No. We trust the end nodes to put the right information in the WESP header. But, we don't trust the intermediaries, that could have mangled the packet so that it goes through the firewall/deep inspection device. If that happens, then the packet should not be consumed, which would make the attack by a malicious middle box worthless. Hope this helps. Manav I don' know about anyone else, but it didn't clarify the threat model for me :-). In some messages the phrase "trusted intermediaries" is used, which does not seem to fit your text above. If you are alluding to a MITM, say so. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ikev2bis clarification on port floating
Scott C Moonen writes: > Tero, > > > > 2) Disallow floating on IKE_SA_INIT unless . . . > > Why do you want to disallow that? . . . > > > > > 3) Disallow this elective use of UDP-encap unless . . . > > Again why do that? > > I guess I'm thinking more about what is advisable (without out-of-band > knowledge or inference) than what is permissible, so that may be out of > scope. And I should have said "recommend against" rather than "disallow". Ok, that makes much more sense. On the other hand the current text tries to make the recipient part so that we do not need to change that, even if someone later proposes modifications that use out-of-band or similar knowledge and defines how those are used. So it is ok to add text saying that you should not use those features as a initiator, but you still must to be able to receive them as a responder. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
