Changes to the -00 version: htmlwdiff.
Elwyn Davies wrote:
One minor issue with regard to the language used about how to model the tunnel end-point when specific SPD tunnel mode is used: I am not sure that it is up to this document to 'require' (s5.3, 2nd para) that they are not modelled as separate interfaces. What we are saying is that it is not really possible to build specific SPD tunnel mode on end points modelled as interfaces... Therefore we recommend that specific SPD tunnel mode end points should not be modelled as separate interfaces. This is followed through into the reccommendations in s9 para 2: suggest s/support/recommend/. There ought to be a better way of saying this but I can't think what it is at present.
The result: Agreed; we changed s/support/recommend/, but also made s/we specifically require that specific/this memo restricts to describing only the scenario where/ in section 5.3.
Elwyn Davies suggested:
A number of language/editorial nits:
s1: Unexpanded acronyms: SA, SPD, ECN (SA is expanded in s2.1)
s2: para 1: s/was mostly/is mostly/
s2: para 3: s/specifies following/specifies the following/,
s/measures./measures:/
s2: paras4/5: make them bulleted paras to clarify that they are the
'following measures'
s2.1: para 1: s/The successful/A successful/
s2.1: last para: s/kind/kinds/
s2.1: last para: Unexpanded acronyms GRE, L2TP (maybe need references).
s2.2: para 1: s/The successful/A successful/
s3.2: next-to-last para: Unexpanded acronyms ISP, CPE
s4: The language in this section may become slightly less clear when the
drafts become RFCs
s4: para 2: s/is defined in [RFC2401] and
[I-D.ietf-ipsec-rfc2401bis]/was originally defined in [RFC2401] now
superseded by [I-D.ietf-ipsec-rfc2401bis]/
s4: para 2: s/IPsec security/The IPsec security/, s/difference/differences/
s4: para 7: Move the first sentence {'IKE is defined in [RFC2409] (which
is referred to as IKE in this document) and in [I-D.ietf-ipsec-ikev2]
(which is referred to as IKEv2 in this document).'} to be the second
sentence of para 2. Start a new para after this, substituting s/them/the
two versions of the security architecture/. In the rest of the section
- do what the IKE sentence says - use IKE and IKEv2 consistently - IKEv1
-> IKE, places where the IKE RFC/draft are used replaced by IKE/IKEv2
(e.g., Bullet point 3), para 6) [Actually IKEv1 seems to be used pretty
consistently in the rest of the document!]
s5: para 1: s/the IPsec tunnel establishment for/establishment of an
IPsec tunnel for the/, s/we'll/we will/, s/look on/look at/
s5: Figure 5: Might be more obvious as a 'boxed' table, maybe with
column headings 'Components (first to last)', 'Contains'. Also
presumably the packet has a payload!
s5.2: para 1: delete 'kind of'
s5.2: para 3: s/whose tunnel endpoint's IPv4 address is/with tunnel
endpoint IPv4 addresses/
s5.2: para 3: s/The implementations/Implementations/
s5.3.1: para 1: s/routing table/the routing table/, s/is passes/is passed/
s5.3.1: para 3: s/prevent/prevent an attacker/
s7: para 2: s/the same way/in the same way/
s7: bullet point 2: s/the NAT changes/where the NAT changes/
s7: last para: s/MOBIKE/The IETF MOBIKE working group/
s8: 1st bullet: s/off-band/out-of-band/
s9: last para: s/is to either tunnel mode with generic SPDs or transport
mode, and applying/is to use either tunnel mode with generic SPDs or
transport mode, and apply/
s11: para 1: s/in the tunnel/into the tunnel/
s11: para 2: s/to the both,/to both/
s11: para 3: IF you use IKE to mean IKEv1 then s/IKE/Either IKE or
IKEv2/ - If you go for IKEv1 explicitly, IKE is finr.
References: Whether RC2401 and RFC2409 are normative is arguable!
App A: para 2: s/associations are/association is, s/interfaces/an interface/
App A: throughout: s/destination/DST/ in rules (some already do)
The result: all of these have been adopted. We clarified that we use "IKEv1" and "IKEv2" to refer to the different IKE versions.
Introduction section motivates the document by pointing to address spoofing. However, IPsec is used for other reasons as well. Several people pointed to the issue of using IPsec to protect the data traffic and to use IPsec as an IPv4/IPv6 transition mechanism. [Florian Weimer] > I think the two threats (IP address spoofing) are not the ones you > want to protect against. You seem to be interested in payload > integrity and confidentiality, too, which is a completely different > matter. [Pekka] These are different, yes. I guess this boils down to two options: 1) protect all tunneled v6 traffic between tunnel encapsulator E1 and decapsulator E2, or 2) protect just the link-local messaging between the tunnel endpoints, but not the data payload. These obviously have different properties. 1) is more like "tunnel mode", possibly for road warrior VPN-like scenarios, and 2) aims to only protect the special link-local messaging which could otherwise be spoofed. IP spoofing prevention is indeed mostly orthogonal, but using IPsec also eliminates that threat to a degree.Later, on section 2.2, Michael Richardson also noted:
[Michael] A tunnel can very well be negotiated for ::/0 -> ::/0. [Pekka] Ack -- that would protect all the payload, and might be the simplest approach. Maybe we should adopt that...
The result: the focus of the document has been changed to include integrity and confidentiality as well (rewording in the threat analysis, and rework of SPD's to protect everything).
Alain Durand asked why the document should be at v6ops and not in the security area.
[Pekka]
The background here is that:
1) trans-mech RFC basically said, "use IPsec if you need security";
this is no longer considered sufficient, and it is required to
describe how exactly you use IPsec if you propose to use it.
2) draft-ietf-v6ops-mech-v2 was revised to just say, "we describe the
use of IPsec for v6-in-v4 tunnels in another document" [this one].
3) Steve Bellovin, while he was security AD, requested
description of IPsec usage (or this document) at his review of
draft-ietf-mech-v2-xx; he wouldn't want to let draft-ietf-mech-v2
go forward to the RFC editor's queue before this is done, so
draft-ietf-v6ops-mech-v2 has been practically stalled from
completion for the last 4 months or so.
[Alain]
A boilerplate explaining the history of this document would be useful.
The result: the first two paragraphs of Introduction were reworded to
better document the reason for this draft:
The IPv6 operations (v6ops) working group has selected (manually
configured) IPv6-in-IPv4 tunneling [I-D.ietf-v6ops-mech-v2] as one of
the IPv6 transition mechanisms for IPv6 deployment.
[I-D.ietf-v6ops-mech-v2] identified a number of threats which had not
been adequately analyzed or addressed in its predecessor, [RFC2893].
The most complete solution is to use IPsec to protect IPv6-in-IPv4
tunneling. The document was intentionally not expanded to include
the details on how to set up an IPsec-protected tunnel in an
interoperable manner, but instead the details were deferred to this
memo.
> Mohan> or BTNS. Perhaps IPsec would have been more adopted if these > Mohan> were already in place. So, i really don't know how to answer > Mohan> this part. Your thoughts would be appreciated.Michael Richardson also discussed:
> Frankly, you need BTNS/OE. > If I get my way, BTNS will be leap-of-faith (no DNS) OE. > > We need to just do it. It works. [Pekka] I agree that BTNS/OE would be highly useful in the cases where you want to secure the traffic easily, and to arbitrary endpoints. However, the main target here are _manually configured_ tunnels. We can assume that tunnel endpoints A and B are known, they may have some out-of-band communication channel, and could even use static keying if it was secure (which it isn't). It would not of course hurt if there was a recipe to setting up up IPsec protected IPv6-in-IPv4 tunnels everywhere, for example, protecting every 6to4 tunnel that is created automatically, but that is out of scope for this draft (IMHO).Irrespective of that, the authors thought that clarifying the scope would be useful:
is it useful/necessary to cover the following aspects: - multihoming - btns - qos - multicast how does it relate to some mip6-multi6-mobike work.The results: extended discussion of BTNS (or how IPsec would be different if it was deployed or not) does not seem relevant here. Further, our focus is solely on configured tunnels, not opportunistic tunnels. Extended discussion of QoS, etc. do not seem warranted either. However, we have a new paragraph at the end of Introduction touching these issues:
This document does not address the use of IPsec for tunnels which are not manually configured (e.g., 6to4 tunnels [RFC3056]). Presumably, some form of opportunistic encryption or "better-than-nothing security" might or might not be applicable. Similarly, propagating quality of service attributes (apart from ECN bits [I-D.ietf-v6ops- mech-v2]) from the encapsulated packets to the tunnel path is out of scope.There is a short mention of mobility aspects at the end of NAT section (with a new section title):
When NAT is not applied, the second benefit would still be desirable. In particular, using manually configured tunneling is an operational challenge with dynamic IP addresses as both ends need to be reconfigured if an address changes. Therefore an easy and efficient way to re-establish the IPsec tunnel if the IP address changes would be desirable. MOBIKE is looking into providing a solution for IKEv2 but the work is still in progress [I-D.ietf-mobike-protocol].
[Michael Richardson]
My opinion is that IPsec tunnel is, by definition:
IPsec transport + IPIP header (of some kind) + ingress filtering
Many people (e.g. Joe Touch responds to Stephen Kent's absolutism)
like think "use" transport+IPIP, do so because they want more flexible filtering.
It has always been my opinion that the "filtering" side is called a
'firewall', and RFC2401 (and -bis) describes IETF standard stateless
firewalling.
Pekka> I'm not sure whether I understood this comment. Were you
Pekka> saying that some include (inside address) ingress filtering
Pekka> automatically as part of IPsec, and some do not? In that
Pekka> case, our assumptions need to be spelled out explicitly.
[Michael]
I'm saying that for people correct understand that tunnel mode is
really about transport mode IPIP + filtering. Some even configure the
two steps seperately.
Others think it is totally seperate thing --- the Stephen Kent view of
2401-IPsec is that it must always be possible to do in a bump-in-the-wire.
As such, it can never communicate with routing, firewalling, etc.
I don't think you want to do that, so I'm saying that you need to
write down what you expect. That may violate some pieces of
2401/2401bis.
I suggest that you do exactly that. You will be writing new code
regardless.
As a customer of IPsec, feel free to actually make it do what you
expect it to.
Elwyn Davies also said a bit more explanation of the alternative
solution would help:
> IPsec tunnel mode SA is recommended for this case which prevents > spoofing completely, though similar amount of protection can be > obtained with transport mode SA with strict ingress filtering (except > for link-local addresses) as well.The result: this has been spelled out in more detail in various places in the document. Further, we now classify transport mode and tunnel mode (with ::/0 <-> ::/0 selectors) largely equivalent. We also describe the more complex specific SPD scenario in an appendix.
Michael Richardson said:
[::/0 -> ::/0 selectors] has some problems for a lot of systems where the IPsec and control plane are seperated. Those systems need another (internal) selector to determine which of the ::/0->::/0 tunnels to use.The result: The use of '::/0 -> ::/0' selectors with tunnel mode has been spelled out, as well as the implications on routing tables etc. The specific selectors are also described, but only in the appendix.
Comment from Eric Vyncke:
section 2.2, should be augmented because tunnel mode prevents the use of multicast (and more generally routing protocols -- cfr Joe Touch's I-D for IPv4) while transport mode does work [..]The result: we now spell out clearly that with transport mode and tunnel mode with generic ::/0 -> ::/0 SPDs, multicast and routing protocols work fine, but with specific SPDs, they are not feasible.
The router-to-router scenario described in Section 3.1 recommends transport mode. However, as noted by Michael Richardson tunnel mode is also feasible (if the same security applies for all tunnels).The result: the text has been greatly enhanced, though the text in section 3.1 has been trimmed down; transport mode and tunnel mode (with generic SPDs) are now largely equivalent.
[ask] for some mention of potential scalability issues here - if i understand correctly a tunnel and SA per host in the site is needed.The result: as described in the section, it is possible to use a prefix notation as well, so you need just a single SA. This is probably caused by a confusion/mis-read. No change.
[Michael]
Unclear to me if /64<->/64 or /128<->/128 are to be
created. Also, given two IPv4 hosts that have an IPv6 application
that wishes to communicate, can they use 6to4 addresses, and then
secure the IPv4?
[Pekka]
Well, they can't use 6to4 unless they have a public address, but..
there are different options. One is as you write, but I think in that
case, I think it would be better to just obtain IPv6 connectivity
somehow (e.g., Teredo, 6to4, whatever), and use IPv6 IPsec between the
two hosts..
[Michael]
Sure. I'm just sure what the policy that will be proposed is going to
be. And if the address is obtained in some way, then how does the
responder know why some random IPv4/udp-port has the authority to assert
some IPv6 on the inside of the tunnel.
The result: the details of proposed IPsec configuration
are in section 5, so they don't really fit here.
Application aspect is also out of scope, as we're
talking about securing configured tunneling, not automatic host-to-host
tunneling. No changes.
[Elywn] S5 (all sections): My understanding (which may be wrong) is that SAs carry either unicast or multicast traffic... some of the SAs defined in the SPD seem to be intended to carry both unicast neighbor discovery/SAAC and the associated MLD Join messages. If this is true separate SAs will be needed [Mohan] Yes. But the intention is to have fewer SPD entries and protect most of the link-local traffic. Otherwise, you need to have more SPD entries to protect the different types of link-local traffic between the two end points. [Elywn] but they can be more tightly defined ... the unicast ones are link local to link local and the multicast ones have a restricted set of multicast groups (All Nodes, All Routers, DHCP groups and Solicited Node groups). .... Thinking further about these comments, i realised I had not been thinking clearly about the S5 issue on unicast vs multicast SAs. The SA is of course for the tunnel which is strictly unicast, so the issue I raised is a red herring. However, it also occurred to me that the specifications intended to cope with neighbor discovery and SAAC may be unnecessarily wide since the only relevant traffic is between the two tunnel end points which constitute the (point-to-point) link in these cases.The results: Elwyn seemed to withdraw unicast/multicast comment. The fact whether the link-local multicast traffic etc. needs SPDs etc. (the last paragraph of Elwyn's comment) depends which mode (tunnel/transport) is used, and how. Link-local traffic would need SPDs for specific-SPD tunnel mode, but we do not believe this is feasible/workable with multiple tunnels so we do not support this in the draft (and we state so).
i think that there was still an open issue regarding the scope of the document. should we cover ikev2 only or also ikev1? the problem is that ikev1 will still be out there for a long time.The result: we're covering both.
the detailed entries of the sad and spd need to be verified.The result: checked but more review would be welcome.
[Florian Weimer] > The draft does not mention RFC 3068 tunnels. This might be > intentional oversight, but should be stated nevertheless. [Pekka] This should be discussed, I think. However, you can (practically) only protect the protocol-41 traffic from you to your relay router, not all the relay routers in the world to you. So, in practice, it is unfeasible to use IPsec here, except possibly for one direction only (and that is likely not worth the trouble, and the anycast relay operator is unlikely to go for it)The result: the authors agreed that as the new Introduction section rules out 6to4 and automatic tunnels, the 6to4 anycast address is also out of scope and no text is needed on this. No changes.
[Michael]
a) what ID to use for IKE?
b) why would I trust it?
c) what authentication mechanism to use.
EAP methods that leverage AAA infrastructure, are the
username/password methods, which are insecure.
As you note the "server" (what's that? i thought we were all peers)
needs a public-key.
Only key generating modes of EAP are secure. That means no
username/password! if you have a key generating mode of EAP, then
odds are that it can be used in IKEv2 directly.
(There are exceptions, such as EAP-SIM or EAP-AKA, but neither are
really that useful in your application)
Pekka> However, the main target here are _manually configured_
Pekka> tunnels. We can assume that tunnel endpoints A and B are
[Michael]
Please say something simple like:
IKEv1 IDs SHOULD be ID_IPV6_ADDR
Leave the choice of PSK, raw-RSA, pre-exchanged self-signed
certificates, etc. up to the admins.
In follow-up discussions, it seemed that EAP isn't really relevant to the
maint topic of this draft.
The results: Section on EAP has been removed. The text already said, "The IDci and IDcr payloads of IKEv1 carry the IPv4-TEP1, IPV4-TEP2 and protocol value 41 as phase 2 identities." (and the like) which seems sufficiently detailed enough; no change to that.
[Michael] TED is not really that useful, doesn't scale, has never been deployed and doesn't really do that much. About the only advantage it has is that Cisco proposed it. If you are going to mention this kind of thing, then Opportunistic Encryption should be mentioned as well.The result: The reference to TED was removed, so mention of OE is not added (here), though it has been briefly mentioned in the introduction.
> >> 5) another use case scenario can be (and actually I've seen it > >> deployed): using this IPsec protected IPv6 tunnel as a back-up link > >> of a 'real native' IPv6 link in order to provide resiliency. This > >> of course requires routing protocols hence the use of the > >> 'transport mode' variant. > > > > I don't know whether it is relevant to the current document or not. > > I will let Pekka answer this. > > (This is my opinion only, of course. :) [pekka] > > As far as I understand, the above is only an issue if the tunnel mode > SA is not modelled as an interface (based on the touch-vpn, now > RFC3884, right? If it's an interface, it could be used to run a > routing protocol (as long as it's not IS-IS :-) just fine? > > I think we are already assuming that it's an interface, and this > should not be an issue? [mohan] I am not sure about this part. I have to read it again to see whether we say this explicitly or not. [pekka] > In any case, section 5.1 already describes transport mode > router-to-router tunneling, which may or may not use lose ingress > filtering capability depending on whether the transport mode is > modelled as an interface or not. > [mohan] This is modeled as an interface because it is normally an IP-IP tunnel + IPsec. [pekka] > So, I guess we already have all the technical bases covered (unless > I'm missing something?), and the issue is just whether this usage > scenario is should be explicitly mentioned in the draft. I'd say not, > because this seems to be a much more specific example case than the > ones we currently have in the draft, and listing a specific one might > be misleading. > [mohan] Agreed. [eric vyncke] It is indeed a variation of router to router scenario as a parallel link. I would not call this a specific case but a variation.The result: the interface assumption has already been been clarified as part of earlier issues. A reference to RFC3884 has been included. We have not seen sufficient justification (or the specific place and how to do so) for describing this particular usage case in the draft. No change.
[michael] > If you wish to negotiate more than one of these SAs between the same > two hosts, yes, you need additional selectors for IKE. This is provided > in IKEv2. Between different end-points, it is okay, as long as your > forwarding plane can cope with the differences. [mohan] I don't know what you mean by "provided" in IKEv2. AFAIK, there is no inter-operable way of doing this. L3VPN documents talk about both IP-IP tranport mode and tunnel mode and leaves out all the details as reader's excersise :-). The folks who have implemented "provider provisioned VPNs" always felt that this was a big gap in the IPsec documents.The result: we don't think it's necessary to have more than one SA between the same two hosts. Does this need spelled out somehow (where?). No changes.
Fred Baker ran id-nits and found some formatting or boilerplate issues.
Jordi Palet suggested changing the title to 'Using IPsec to Secure IPv6-in-IPv4 Tunnels' to not confuse this to 6over4.
> The IPv4 addresses may be spoofed and IPsec cannot detect it in this
> mode, that is, two nodes that are using IPsec tunnel mode to secure
> the tunnel with a common tunnel endpoint can spoof each other's IPv4
> address. But, the packet will not be accepted by IPsec as the IPv6
> address bound to the SA will not match the address in the spoofed
> packet. Thus, the outer address spoofing is irrelevant as long as
> the inner IPv6 packet can be verified to come from the right IPv6
> endpoint.
[Michael]
First, the IPv4 outer address can indeed be spoofed. (that means
that it arrives with a correct value from a wrong sender. Without
crypto, you can not tell that it is wrong)
But, if the crypto is good, who cares. The outer IPv4 is not really
relevant at all. That's why ESP often appears to work through NATs.
If you have two tunnel end points that are sharing keying materials,
then yes, they can spoof each other packets.
A tunnel may be shared between two senders *ONLY* if replay
protection is turned off. In general, this follows into multicast
(with multiple senders) space.
The general view is: DO NOT SHARE TUNNELS.
It is cryptographically bad.
[Pekka] Yes, this is what the text is intended to say, but some rewording it
obviously needed..
The result: this has been reworded:
The outer IPv4 addresses may be spoofed and IPsec cannot detect it in this mode, but the packet will not be accepted by IPsec as the IPv6 address bound to the SA will not match the address in the spoofed packet. Thus, the outer address spoofing is irrelevant as long as the inner IPv6 packet can be verified to come from the right tunnel endpoint.
Kurt Erik Lindqvist said:
Page2: On (2), it might be worth nothing that escaping the ingress-filtering will only happen if the tunnel end-point is "deep" into the network. I.e if this is the IPv6 networks connection to the outside world it might very well be ingress-filtered. But this is nit-picking. It's just that I read the text as it would not be possible to do ingress-filtering.The result: as going into depth about ingress filtering would be out of scope, we've just reworded "escapes ingress filtering" to "may escape ingress filtering".
Kurt Erik Lindqvist said:
Page4: I am having a hard time to understand the generalisation of site-to-router/router-to-site of host-to-router and v.v ?The result: After some clarification on the comment, it was clear that "site" and "router" are unclear, and used here for shorthand purposes. We've now spelled this out a bit:
3. Scenarios and Overview
There are roughly three kinds of scenarios:
1. (generic) router-to-router tunnels.
2. site-to-route/router-to-site tunnels. This refers to a tunnel
between a site's IPv6 (border) device to an IPv6 upstream
provider's router. A degenerate case of a site is a single host.
3. Host-to-host tunnels.
Kurt Erik Lindqvist wrote and we discussed this:
[Kurtis]
Page5: 3.2. I am not sure I agree that the situation for site-router and host-router is the same,
especially with what options you would have for ingress-filtering.
[Pekka]
> Could you elaborate on that comment a bit? I don't see much difference here. In one, you
> ingress filter a /128. In the other, you ingress filter a /48 (or whatever). Either could be
> multihomed.
[Kurtis]
So I think what had me a bit confused was ' The CPE (where the tunnel is terminated) "trusts" (in
a weak sense) the ISP's router and the ISP's router can verify that the Site B is the only one
that can originate packets within the /48.'
If this is a "site" the upstream provider would simply static route a /48 to the site. If is a
host, The provider actually don't know which /128 to filter for. AFAICS? I must be missing
something.
[Pekka]
> For site case, yes, though upstream provider could use something like DHCPv6-PD as well, and
> then it might not be able to just apply regular access-lists as the prefix might or might not
> change, but could use strict uRPF.
>
> For host case, you may be thinking of the case where the ISP would do RFC2461 RAs for the whole
> /64, and the host would pick and automatically generate an address. Tunneling from a host
> obviously requires some amount of manual configuration.
>
> I wonder if this clarifies at all..?
[Kurtis]
I think that what would clarify it a bit would be note that the document assumes there is some
level of manual configuration that will act as support for the ingress-filtering, but that that
won't effect the IPsec tunnels. ?
The result: We've added a very brief note on this at the end; better
suggestions, if more clarification is needed, would be welcome.
IPv6 spoofing must be prevented, and setting up ingress filtering may require some amount of manual configuration; see more of these options in Section 5.
Elwyn Davies said:
S5: Where the SPD rule applies to a prefix, it might be clearer to use a different operator (like ~) to indicate prefix matching rather than equality (=).The result: SPD configurations have been adopted from other specs, while pedantically something else than "=" would be better, we believe this is sufficient in clarity and in line with other specs. No change.
Elwyn Davies said:
S5:the packet format piece at the end of the section probably deserves a separate section.The result: the packet formats were moved at the start of section 5.