Hi, RFC4555 only allows updates to tunnel endpoint addresses and not selectors, etc. Does anyone know why TS updates are not permitted? If MOBIKE allowed what an SA rekey would allow, what is the problem? Thanks, Vidya
FYI: https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=851
The IESG has received a request from the Mobility for IPv4 WG (mip4) to
consider the following document:
- 'Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE '
<draft-ietf-mip4-mobike-connectivity-02.txt> as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2007-02-06. Exceptionally,
comments may be sent to iesg <at> ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivity-02.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14170&rfc_flag=0
Hi, Sorry if you receive this mail twice. Yoav and I would appreciate any comments you may have to this draft, either privately or to the IPsec mailing list. Thanks, Yaron -----Original Message----- From: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org] Sent: Monday, November 27, 2006 17:50 To: i-d-announce <at> ietf.org Subject: I-D ACTION:draft-sheffer-ipsec-secure-beacon-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure Beacon: Securely Detecting a Trusted Network Author(s) : Y. Nir, Y. Sheffer Filename : draft-sheffer-ipsec-secure-beacon-01.txt Pages : 12 Date : 2006-11-27 Remote access clients, in particular IPsec-based ones, are heavily deployed in enterprise environments. In many enterprises the security policy allows remote-access clients to switch to unprotected operation when entering the trusted network. This document specifies a method that lets a client detect this situation in a secure manner, with the help of a security gateway. We propose a minor extension to(Continue reading)
_______________________________________________ Mobike mailing list Mobike <at> machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike
_______________________________________________ Mobike mailing list Mobike <at> machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike
RFC 4555, Sec. 3.3 says that if both peers support MOBIKE and NAT-T, then they must change to port 4500 even if NAT was not detected between them. But in the design document, RFC 4621, Sec 5.2.3 says that the port change should be done immediately after IKE_SA_INIT and before IKE_AUTH. However, support for MOBIKE is declared during the IKE_AUTH exchange. I suppose it's not a big deal, since peers will be listening on port 4500 anyway. But when should the initiator and responder change ports in the scenario where there is no NAT between them?
1) When the initiator detects a change in its NAT mapping (from a received NAT_DETECTION_DESTINATION_IP payload), it does not actually know what the new mapping is, and hence, following Sec. 3.5, does nothing to change its IKE_SA, correct? It only sends UPDATE_SA_ADDRESSES to tell the peer to update its SAs' tunnel endpoints. 2) Can other INFORMATIONAL exchanges be used to detect changes in NAT mapping? Sec 3.8 seems to imply only the IKE_SA_INIT exchange and exchanges containing UPDATE_SA_ADDRESSES should be used.
A new Request for Comments is now available in online RFC libraries.
RFC 4621
Title: Design of the IKEv2 Mobility
and Multihoming (MOBIKE) Protocol
Author: T. Kivinen, H. Tschofenig
Status: Informational
Date: August 2006
Mailbox: kivinen <at> safenet-inc.com,
Hannes.Tschofenig <at> siemens.com
Pages: 30
Characters: 73070
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-mobike-design-08.txt
URL: http://www.rfc-editor.org/rfc/rfc4621.txt
The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension
of the Internet Key Exchange Protocol version 2 (IKEv2). These
extensions should enable an efficient management of IKE and IPsec
Security Associations when a host possesses multiple IP addresses
and/or where IP addresses of an IPsec host change over time (for
example, due to mobility).
This document discusses the involved network entities and the
relationship between IKEv2 signaling and information provided by
other protocols. Design decisions for the MOBIKE protocol,
background information, and discussions within the working group are
recorded. This memo provides information for the Internet community.
This document is a product of the IKEv2 Mobility and Multihoming
Working Group of the IETF.
INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info <at> RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute
...
Here is list of changes to the draft-ietf-mobike-design-08.txt from
the IESG etc. I think all of those are minor editorial comments that
can be put into to the document during AUTH48 (or actually rfc-editor
can put them in directly while editing the draft if they like).
----------------------------------------------------------------------
Change in section 3.1 (from Lisa, changed "mobile node" to "mobile node (MN)")
3.1. Mobility Scenario
Figure 1 shows a break-before-make mobility scenario where a mobile
node changes its point of network attachment. Prior to the change,
the mobile node had established an IPsec connection with a security
gateway which offered, for example, access to a corporate network.
The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took
place over the path labeled as 'old path'. The involved packets
carried the MN's "old" IP address and were forwarded by the "old"
access router (OAR) to the security gateway (GW).
To
3.1. Mobility Scenario
Figure 1 shows a break-before-make mobility scenario where a mobile
node (MN) changes its point of network attachment. Prior to the
change, the mobile node had established an IPsec connection with a
security gateway which offered, for example, access to a corporate
network. The IKEv2 exchange that facilitated the setup of the IPsec
SA(s) took place over the path labeled as 'old path'. The involved
packets carried the MN's "old" IP address and were forwarded by the
"old" access router (OAR) to the security gateway (GW).
----------------------------------------------------------------------
Change title of 5.2 (from Lisa, added "(NAT-T)")
5.2. NAT Traversal
To
5.2. NAT Traversal (NAT-T)
----------------------------------------------------------------------
Change in section 1 (From Russ, changed RFC2401bis to "the Security
Architecture for the Internet Protocol", Eric Gray noted same)
The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306]. As
IKEv2 is built on the architecture described in RFC2401bis [RFC4301],
all protocols developed within the MOBIKE working group must be
compatible with both IKEv2 and the architecture described in RFC4301.
This document does not discusses mobility and multi-homing support
for IKEv1 [RFC2409] nor the IPsec architecture described in RFC2401
[RFC2401].
To
The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306].
As IKEv2 is built on the architecture described in the Security
Architecture for the Internet Protocol [RFC4301], all protocols
developed within the MOBIKE working group must be compatible with
both IKEv2 and the architecture described in RFC4301. This document
does not discusses mobility and multi-homing support for IKEv1
[RFC2409] nor the IPsec architecture described in RFC2401
[RFC2401].
----------------------------------------------------------------------
Change in sectin 4 (From Russ, changed "IKE" to "IKEv2")
4. Scope of MOBIKE
Getting mobility and multihoming actually working requires many
different components to work together, including coordinating
decisions between different layers, different mobility mechanisms,
and IPsec/IKE. Most of those aspects are beyond the scope of MOBIKE:
To
4. Scope of MOBIKE
Getting mobility and multihoming actually working requires many
different components to work together, including coordinating
decisions between different layers, different mobility mechanisms,
and IPsec/IKEv2. Most of those aspects are beyond the scope of
MOBIKE:
----------------------------------------------------------------------
Change in section 5.1 (From Russ, changed ":" to ".")
5.1. Choosing Addresses
One of the core aspects of the MOBIKE protocol is the selection of
the address for the IPsec packets we send. Choosing addresses for
the IKEv2 request is a somewhat separate problem: in many cases, they
will be the same (and in some design choice they will always be the
same, and could be forced to be the same by design).
To
5.1. Choosing Addresses
One of the core aspects of the MOBIKE protocol is the selection of
the address for the IPsec packets we send. Choosing addresses for
the IKEv2 request is a somewhat separate problem. In many cases, they
will be the same (and in some design choice they will always be the
same, and could be forced to be the same by design).
----------------------------------------------------------------------
Change in section 5.1.1 (from Russ, change ", e.g., Mobile IP, and" to
"other mobility protocols such as Mobile IP, and they")
These triggers are largely the same as for, e.g., Mobile IP, and are
beyond the scope of MOBIKE.
To
These triggers are largely the same as for other mobility protocols
such as Mobile IP, and they are beyond the scope of MOBIKE.
----------------------------------------------------------------------
Change in section 5.1.2 (from Russ, changed "address the request came
from" to "address from which the request came")
There can be two kinds of connectivity "failures": local failures and
path failures. Local failures are problems locally at an MOBIKE peer
(e.g., an interface error). Path failures are a property of an
address pair and failures of nodes and links along this path. MOBIKE
does not support unidirectional address pairs. Supporting them would
require abandoning the principle of sending an IKEv2 reply to the
address the request came from. MOBIKE decided to deal only with
bidirectional address pairs. It does consider unidirectional address
pairs as broken, and does not use them, but the connection between
peers will not break even if unidirectional address pairs are
present, provided there is at least one bidirectional address pair
MOBIKE can use.
To
There can be two kinds of connectivity "failures": local failures and
path failures. Local failures are problems locally at an MOBIKE peer
(e.g., an interface error). Path failures are a property of an
address pair and failures of nodes and links along this path. MOBIKE
does not support unidirectional address pairs. Supporting them would
require abandoning the principle of sending an IKEv2 reply to the
address from which the request came. MOBIKE decided to deal only with
bidirectional address pairs. It does consider unidirectional address
pairs as broken, and does not use them, but the connection between
peers will not break even if unidirectional address pairs are
present, provided there is at least one bidirectional address pair
MOBIKE can use.
----------------------------------------------------------------------
Change in section 5.2.1 (from Russ, ", i.e., if" to ". If")
The NAT-T support should also be optional, i.e., if the IKEv2
implementation does not implement NAT-T, as it is not required in
some particular environment, implementing MOBIKE should not require
adding support for NAT-T either.
To
The NAT-T support should also be optional. If the IKEv2
implementation does not implement NAT-T, as it is not required in
some particular environment, implementing MOBIKE should not require
adding support for NAT-T either.
----------------------------------------------------------------------
Change in section 5.2.2 (from Russ, "old" to "the old")
There are some cases which cannot be carried out within MOBIKE. One
of those cases is the case where the party "outside" a symmetric NAT
changes its address to something not known by the the other peer (and
old address has stopped working). It cannot send a packet containing
the new addresses to the peer because the NAT does not contain the
necessary state. Furthermore, since the party behind the NAT does
not know the new IP address, it cannot cause the NAT state to be
created.
To:
There are some cases which cannot be carried out within MOBIKE. One
of those cases is the case where the party "outside" a symmetric NAT
changes its address to something not known by the the other peer (and
the old address has stopped working). It cannot send a packet containing
the new addresses to the peer because the NAT does not contain the
necessary state. Furthermore, since the party behind the NAT does
not know the new IP address, it cannot cause the NAT state to be
created.
----------------------------------------------------------------------
Change in section 5.2.4 (from Russ, change "where the responder can
move to," to "to which the responder can move." and change "i.e. the"
to "That is, the").
MOBIKE can work in cases where the responder is behind static NAT,
but in that case the initiator needs to know all the possible
addresses where the responder can move to, i.e. the responder cannot
move to an address which is not known by the initiator, in case
initiator also moves behind NAT.
To
MOBIKE can work in cases where the responder is behind static NAT,
but in that case the initiator needs to know all the possible
addresses to which the responder can move. That is, the responder
cannot move to an address which is not known by the initiator, in
case initiator also moves behind NAT.
----------------------------------------------------------------------
Change in section 5.2.5 (from Russ, change ", i.e. if" to ". If")
One new feature created by MOBIKE is NAT prevention, i.e. if we
detect NAT between the peers, we do not allow that address pair to be
used. This can be used to protect IP addresses in cases where it is
known by the configuration that there is no NAT between the nodes
(for example IPv6, or fixed site-to-site VPN). This avoids any
possibility of on-path attackers modifying addresses in headers.
This feature means that we authenticate the IP-address and detect if
they were changed. As this is done on purpose to break the
connectivity if NAT is detected, and decided by the configuration,
there is no need to do UNSAF processing.
To
One new feature created by MOBIKE is NAT prevention. If we
detect NAT between the peers, we do not allow that address pair to be
used. This can be used to protect IP addresses in cases where it is
known by the configuration that there is no NAT between the nodes
(for example IPv6, or fixed site-to-site VPN). This avoids any
possibility of on-path attackers modifying addresses in headers.
This feature means that we authenticate the IP-address and detect if
they were changed. As this is done on purpose to break the
connectivity if NAT is detected, and decided by the configuration,
there is no need to do UNSAF processing.
----------------------------------------------------------------------
Change in section 5.4 (from Russ, change "IKE-SA" to "IKE SA" to be
consistent in document)
o MOBIKE signaling messages are also ignored. The IKE-SA must not
be deleted and the suspend functionality (realized with the zero
address set) may require the IKE-SA to be tagged with a lifetime
value since the IKE-SA should not be kept alive for an undefined
period of time. Note that IKEv2 does not require that the IKE-SA
has a lifetime associated with it. In order to prevent the IKE-SA
from being deleted the dead-peer detection mechanism needs to be
suspended as well.
To
o MOBIKE signaling messages are also ignored. The IKE SA must not
be deleted and the suspend functionality (realized with the zero
address set) may require the IKE SA to be tagged with a lifetime
value since the IKE SA should not be kept alive for an undefined
period of time. Note that IKEv2 does not require that the IKE SA
has a lifetime associated with it. In order to prevent the IKE SA
from being deleted the dead-peer detection mechanism needs to be
suspended as well.
----------------------------------------------------------------------
Change in section 5.5.2 (from Russ, add comma to "On the other hand,
return ...")
If the return routability check fails, we need to tear down the IKE
SA if we are using IKEv2 INFORMATIONAL exchanges to send return
routability checks. On the other hand return routability check can
only fail permanently if there was an attack by the other end, thus
tearing down the IKE SA is a suitable action in that case.
To
If the return routability check fails, we need to tear down the IKE
SA if we are using IKEv2 INFORMATIONAL exchanges to send return
routability checks. On the other hand, return routability check can
only fail permanently if there was an attack by the other end, thus
tearing down the IKE SA is a suitable action in that case.
----------------------------------------------------------------------
Change in section 5.6 (from Russ and Brian, change "but will" to "and
might be")
Current MOBIKE design is focused only on the VPN type usage and
tunnel mode. Transport mode behavior would also be useful, but will
be discussed in future documents.
To
Current MOBIKE design is focused only on the VPN type usage and
tunnel mode. Transport mode behavior would also be useful and
might be be discussed in future documents.
----------------------------------------------------------------------
Change in section 6.2 (from Russ, change "packets. I.e. a" to
"packets; a")
Working group decided to use normal IKEv2 exchanges for path testing,
and decided to change the dynamic address updating of NAT-T to MUST
NOT for IKE SA packets. I.e. a new protocol outside of IKEv2 was not
adopted.
To
Working group decided to use normal IKEv2 exchanges for path testing,
and decided to change the dynamic address updating of NAT-T to MUST
NOT for IKE SA packets; a new protocol outside of IKEv2 was not
adopted.
----------------------------------------------------------------------
Change in section 6.3 (from Russ, change "notify, i.e. there" to
"notify. There")
Working group decided to use IKEv2 Notify payloads, and put only one
data item per notify, i.e. there will be one Notify payload for each
item to be sent.
To
Working group decided to use IKEv2 Notify payloads, and put only one
data item per notify. There will be one Notify payload for each
item to be sent.
----------------------------------------------------------------------
Change in section 6.4 (from Russ, change "IP-addresses" to "IP
addresses", this same change should be done on section 5.2.5, 6.2 (2
times), and here).
Working group decided to use a protocol format where both ends send a
full list of their addresses to the other end, and that list
overwrites the previous list. To support NAT-T the IP-addresses of
the received packet are considered as one address of the peer, even
when not present in the list.
To
Working group decided to use a protocol format where both ends send a
full list of their addresses to the other end, and that list
overwrites the previous list. To support NAT-T the IP addresses of
the received packet are considered as one address of the peer, even
when not present in the list.
----------------------------------------------------------------------
Change in section 7 (from Russ, change "modify" to "undetectedly
modify").
As all the packets are already authenticated by IKEv2 there is no
risk that any attackers would modify the contents of the packets.
The IP addresses in the IP header of the packets are not
authenticated, thus the protocol defined must take care that they are
only used as an indication that something might be different, and
that do not cause any direct actions, except when doing NAT
Traversal.
To
As all the packets are already authenticated by IKEv2 there is no
risk that any attackers would undetectedly modify the contents of
the packets. The IP addresses in the IP header of the packets are
not authenticated, thus the protocol defined must take care that
they are only used as an indication that something might be
different, and that do not cause any direct actions, except when
doing NAT Traversal.
----------------------------------------------------------------------
--
--
kivinen <at> safenet-inc.com
Visit %3Cahref%3Dhttp%3A%2F%2Farbat.or.at%2Fadipex%2F%3Ehttp%3A%2F%2Farbat.or.at%2Fadipex%2F%3C%2Fa%3E%3Cahref%3Dhttp%3A%2F%2Farbat.or.at%2Fxanax%2F%3Ehttp%3A%2F%2Farbat.or.at%2Fxanax%2F%3C%2Fa%3E%3Cahref%3Dhttp%3A%2F%2Farbat.or.at%2Fphentermine%2F%3Ehttp%3A%2F%2Farbat.or.at%2Fphentermine%2F%3C%2Fa%3E%3Cahref%3Dhttp%3A%2F%2Farbat.or.at%2Fcialis%2F%3Ehttp%3A%2F%2Farbat.or.at%2Fcialis%2F%3C%2Fa%3E%3Cahref%3Dhttp%3A%2F%2Farbat.or.at%2Fviagra%2F%3Ehttp%3A%2F%2Farbat.or.at%2Fviagra%2F%3C%2Fa%3E
 |
|
|
|
|
|
|
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
RSS Feed15 | |
|---|---|
1 | |
1 | |
1 | |
4 | |
2 | |
5 | |
4 | |
4 | |
3 | |
28 | |
13 | |
18 | |
63 | |
24 | |
78 | |
160 | |
137 | |
46 | |
74 | |
20 | |
55 | |
29 | |
75 | |
27 | |
31 | |
92 | |
66 | |
79 | |
33 | |
54 | |
14 | |
61 | |
22 | |
33 | |
4 |