Pekka Savola | 1 Sep 07:14 2006
Picon

Re: Remove tunnel mode from ipsec-tunnels-02?

Folks,

Unless we hear more comments on this, we propose to go forward with 
the initial suggestion of removing tunnel mode from the main 
specification.

If you have comments, please respond within a week.

For the authors,

On Wed, 12 Jul 2006, Pekka Savola wrote:
> As proposed at the v6ops meeting [0], the authors of 
> draft-ietf-v6ops-ipsec-tunnels-02 propose to remove support for tunnel mode 
> in this particular context (securing v6-in-v4 configured tunnels).
>
> This is due to issues spotted by Francis [1] and Pasi [2].  Generic "::/0 -> 
> ::/0" selectors could not be made to work without interface-specific SPDs, 
> and those cannot be signalled in IKE (that's run on top of IPv4) when the 
> tunnel would be IPv6 in a standardized way.  Generic selectors are required 
> for link-local traffic (e.g., ND) to work on the tunnel.
>
> If we go through with this proposed resolution, 
> draft-ietf-v6ops-ipsec-tunnels would only describe transport mode.
>
> Comments are welcome.
>
> [0] http://www3.ietf.org/proceedings/06jul/slides/v6ops-4.pdf
> [1] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00159.html
> [2] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00230.html
>
(Continue reading)

Internet | 5 Sep 16:50 2006
Picon

I-D ACTION:draft-ietf-v6ops-security-overview-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: IPv6 Transition/Co-existence Security Considerations
	Author(s)	: E. Davies, et al.
	Filename	: draft-ietf-v6ops-security-overview-05.txt
	Pages		: 40
	Date		: 2006-9-5
	
The transition from a pure IPv4 network to a network where IPv4 and
IPv6 co-exist brings a number of extra security considerations that
need to be taken into account when deploying IPv6 and operating the
dual-protocol network and the associated transition mechanisms.  This
document attempts to give an overview of the various issues grouped
into three categories:
   o  issues due to the IPv6 protocol itself,
   o  issues due to transition mechanisms, and
   o  issues due to IPv6 deployment.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@... with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
(Continue reading)

Elwyn Davies | 5 Sep 18:54 2006

New version of Security Overview published

A new version of IPv6 Transition/Co-existence Security Considerations 
(draft-ietf-v6ops-security-overview-05.txt) has been published today.  
This version is intended to address the comments made during IESG 
evaluation, including comments from the General Area Reviewer and the 
Security Directorate Reviewer.  A significant number of essentially 
editorial changes have been made plus some minor technical changes in 
s2.1.11 and s2.1.12.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-05.txt

The main reasons that changes have been made are:
1. To heavily emphasise that certain recommendations could lead to legal 
but unusual traffic being dropped: the document highlights (and has 
always done so) a number of areas where the IPv6 protocol specification 
leaves the door open to a malicious node sending damaging traffic that 
is technically within the specification  but would only be likely to be 
sent with malicious intent. Recommendations are made in the document 
that suggest how to minimize the risk from such traffic.  The warnings 
to administrators to be aware of the trade-offs (security gain vs 
potential for a very limited amount of legitimate traffic being dropped) 
have been reinforced, and the need for monitoring the effects of the 
rules highlighted.  The actual recommendations have not been changed 
except for one case related to link local addresses.
2. Documented the trade-off relating to the extensibility of the IPv6 
header chain: allowing unrestricted access for packets with unknown 
headers and options vs maximum security.
3. The draft previously referred to a number of expired drafts from 
which issues have been collected.  These references have been removed.  
They have been replaced by a small amount of additional explanatory text 
(Continue reading)

Fred Baker | 6 Sep 00:01 2006
Picon

Re: Remove tunnel mode from ipsec-tunnels-02?

given that there are significant networks that operate in tunnel  
mode, including both corporate VPNs and military networks that use  
tunnel mode between encryption devices with a specific view to hiding  
interior addressing and therefore military asset distribution from  
prying eyes, this proposal seem profoundly silly.

Maybe you could remind us why the v6ops working group is supposed to  
be overriding the recommendation of the ipsec working group on how  
security is supposed to work based on what is convenient to IPv6?

On Sep 1, 2006, at 1:14 PM, Pekka Savola wrote:

> Unless we hear more comments on this, we propose to go forward with  
> the initial suggestion of removing tunnel mode from the main  
> specification.

Tschofenig, Hannes | 6 Sep 17:23 2006
Picon

AW: Remove tunnel mode from ipsec-tunnels-02?

Hi Pekka, 

I think it would be a very bad idea to remove the tunnel mode from the document. To me this is clearly an
extremely useful part. 

Ciao
Hannes

PS: I will try to compile a text proposal to improve the current description. 

> -----Urspr√ľngliche Nachricht-----
> Von: owner-v6ops@... 
> [mailto:owner-v6ops@...] Im Auftrag von Fred Baker
> Gesendet: Mittwoch, 6. September 2006 00:01
> An: Pekka Savola
> Cc: v6ops@...
> Betreff: Re: Remove tunnel mode from ipsec-tunnels-02?
> 
> given that there are significant networks that operate in tunnel  
> mode, including both corporate VPNs and military networks that use  
> tunnel mode between encryption devices with a specific view 
> to hiding  
> interior addressing and therefore military asset distribution from  
> prying eyes, this proposal seem profoundly silly.
> 
> Maybe you could remind us why the v6ops working group is supposed to  
> be overriding the recommendation of the ipsec working group on how  
> security is supposed to work based on what is convenient to IPv6?
> 
> On Sep 1, 2006, at 1:14 PM, Pekka Savola wrote:
(Continue reading)

Pekka Savola | 7 Sep 09:57 2006
Picon

Re: Remove tunnel mode from ipsec-tunnels-02?

On Wed, 6 Sep 2006, Fred Baker wrote:
> given that there are significant networks that operate in tunnel mode, 
> including both corporate VPNs and military networks that use tunnel mode 
> between encryption devices with a specific view to hiding interior addressing 
> and therefore military asset distribution from prying eyes, this proposal 
> seem profoundly silly.

Our assumption has been that transport mode is applied to a tunnel 
interface (such as IPv6-in-IPv4, GRE etc).  That hides the inner 
addresses from those observers that would have been on-path in the 
tunnel.

When IPsec tunnel mode is _NOT_ modelled as an interface, then this is 
OK though IMHO suboptimal because you cannot in practice run neighbor 
discovery, routing protocols, multicast etc. over such tunnels.  Due 
to the link-local issues mentioned previously, tunnel mode is not 
something we can recommend when it's modelled as an interface.

If there is something you disagree with in the above two paragraphs, 
maybe you should clarify what the deployment looks like, because there 
are a lot of different variations how IPsec could be applied:

  a) transport mode in host-to-host mode (end-to-end IPsec)
  b) transport mode when applied to an IP tunnel interface (e.g., 
between security gateways or a security gateway and a node)
  c) tunnel mode, not modelled as an interface
  d) tunnel mode, modelled as an interface

a) is out of scope of this document. b) seems best option by far.  c) 
can also work but has more more limited applicability as routing 
(Continue reading)

Myung-Ki Shin | 8 Sep 06:08 2006
Picon

Dual Stack Moving Internet (DSMI)

Hi folks,

I and some of related people are trying to propose a new BoF,
(Dual Stack Moving Internet (DSMI))at upcoming IETF-67 and the
discussion with ADs is in progress (it is not fixed yet).

http://icl.kut.ac.kr/dsmi

Here's a mailing list for the issue discussion :

   General Discussion: dsmi@...
   To Subscribe: http://icl.kut.ac.kr/mailman/listinfo/dsmi

The objective of this BoF is to develop a mobility management
protocol that supports dual stack mobile node's roaming over
IPv6 and IPv4 NETLMM domains with single IP address and does
not require additional host-side software update.

At this time, there is a related draft.
http://www.ietf.org/internet-drafts/draft-jeong-netlmm-dual-stack-moving-ps-00.txt

Please make comments on this stuff and don't hesitate to ask further 
question.

Hopefully, I will request to schedule this BoF, if we identify what a
this BoF would like to do and discussion is mature before cutoff
(Sept. 25).

Regards,
Myung-Ki,
(Continue reading)

Henrik Levkowetz | 8 Sep 09:35 2006

Re: [netlmm] Dual Stack Moving Internet (DSMI)

Hi,

(removing most Cc:s)

I'm responding to this on the NETLMM list, where it seems to belong,
without cross-posting to MIP6 and V6OPS.

	Henrik

on 2006-09-08 06:08 Myung-Ki Shin said the following:
> Hi folks,
> 
> I and some of related people are trying to propose a new BoF,
> (Dual Stack Moving Internet (DSMI))at upcoming IETF-67 and the
> discussion with ADs is in progress (it is not fixed yet).
> 
> http://icl.kut.ac.kr/dsmi
> 
> Here's a mailing list for the issue discussion :
> 
>    General Discussion: dsmi <at> icl.kut.ac.kr
>    To Subscribe: http://icl.kut.ac.kr/mailman/listinfo/dsmi
> 
> The objective of this BoF is to develop a mobility management
> protocol that supports dual stack mobile node's roaming over
> IPv6 and IPv4 NETLMM domains with single IP address and does
> not require additional host-side software update.
> 
> At this time, there is a related draft.
> http://www.ietf.org/internet-drafts/draft-jeong-netlmm-dual-stack-moving-ps-00.txt
(Continue reading)

Fred Baker | 8 Sep 23:17 2006
Picon

draft-ietf-v6ops-routing-guidelines-00.txt

So Marc posted the WG version of his document. Would folks please  
read it and comment to the list?

Fred Baker | 9 Sep 00:33 2006
Picon

Re: Remove tunnel mode from ipsec-tunnels-02?


On Sep 7, 2006, at 3:57 PM, Pekka Savola wrote:
> On Wed, 6 Sep 2006, Fred Baker wrote:
>> given that there are significant networks that operate in tunnel  
>> mode, including both corporate VPNs and military networks that use  
>> tunnel mode between encryption devices with a specific view to  
>> hiding interior addressing and therefore military asset  
>> distribution from prying eyes, this proposal seem profoundly silly.
>
> Our assumption has been that transport mode is applied to a tunnel  
> interface (such as IPv6-in-IPv4, GRE etc).  That hides the inner  
> addresses from those observers that would have been on-path in the  
> tunnel.

well, yes, that's one way that tunnel mode is often implemented. It's  
hardly the only way.

> When IPsec tunnel mode is _NOT_ modelled as an interface, then this  
> is OK though IMHO suboptimal because you cannot in practice run  
> neighbor discovery, routing protocols, multicast etc. over such  
> tunnels.  Due to the link-local issues mentioned previously, tunnel  
> mode is not something we can recommend when it's modelled as an  
> interface.

I'm not entirely sure what the modeling question means to you. Are  
you objecting to the use of a tunnel header, or the configuration of  
an interface to do this?

Good grief.

(Continue reading)


Gmane