headers
The IESG | 6 Nov 2002 21:39
Picon
Favicon

Last Call: Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP) to Proposed Standard


The IESG has received a request from the Layer Two Tunneling Protocol 
Extensions Working Group to consider Signalling of Modem-On-Hold status 
in Layer 2 Tunneling Protocol (L2TP) <draft-ietf-l2tpext-v92-moh-02.txt> 
as a Proposed Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2002-12-6.

Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-v92-moh-02.txt
Permalink | Reply | 0 comments |
headers
James Huang | 7 Nov 2002 01:11
Favicon

UDP-encapsulated IPsec Transport mode

Hi all,
	In the appendix A of draft-ietf-ipsec-udp-encaps-04.txt, there is
some discussions on the issue of multiple clients running UDP-encapsulated
IPsec transport mode tunnels behind a NAT box.  However, I did not find any
discussion on another related issue:  In the traffic selector (ID) payload
the client sends out during quick mode exchange, should the client use its
own private address or the public routable address (i.e. the NAT box's
public IP address)?  If it the later, how does the client know about that
public address?  This seems to be a serious issue, especially for L2TP
voluntary tunnels secured by IPsec (in transport mode).

Regards,
James C. Huang
Permalink | Reply | 0 comments |
headers
James Huang | 7 Nov 2002 01:11
Favicon

UDP-encapsulated IPsec Transport mode

Hi all,
	In the appendix A of draft-ietf-ipsec-udp-encaps-04.txt, there is
some discussions on the issue of multiple clients running UDP-encapsulated
IPsec transport mode tunnels behind a NAT box.  However, I did not find any
discussion on another related issue:  In the traffic selector (ID) payload
the client sends out during quick mode exchange, should the client use its
own private address or the public routable address (i.e. the NAT box's
public IP address)?  If it the later, how does the client know about that
public address?  This seems to be a serious issue, especially for L2TP
voluntary tunnels secured by IPsec (in transport mode).

Regards,
James C. Huang
Permalink | Reply | 0 comments |
headers
Markus Stenberg | 7 Nov 2002 08:51
Picon
Picon
Favicon

Re: UDP-encapsulated IPsec Transport mode

James Huang <james.huang <at> watchguard.com> writes:
> Hi all,
> 	In the appendix A of draft-ietf-ipsec-udp-encaps-04.txt, there is
> some discussions on the issue of multiple clients running UDP-encapsulated
> IPsec transport mode tunnels behind a NAT box.  However, I did not find any
> discussion on another related issue:  In the traffic selector (ID) payload
> the client sends out during quick mode exchange, should the client use its
> own private address or the public routable address (i.e. the NAT box's
> public IP address)?  If it the later, how does the client know about that
> public address?  This seems to be a serious issue, especially for L2TP
> voluntary tunnels secured by IPsec (in transport mode).

L2TP specific issues I am blissfully unaware of; however, because the NAT
boxes are not neccessarily even controlled by the IPsec user, sending the
public address is not really an option that can be supported everywhere.

Here's how the information flow goes as far as I see it:

 Public address doesn't really need to be sent in any case as the remote
 side's public address is the address we're talking IKE with (or at least
 remote address+port combination, but in NAPT case you don't really have
 more of an remote address in any case).

 Private address that is used by the OS for actual traffic is provided
 within the NAT-OA payload so the checksums et al can be corrected.

Therefore, at least as far as implementation I used to work on goes, ID
payload in transport mode case doesn't matter (I seem to recall we sent
private address, but pretty much ignored what was sent by remote).
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Huang | 7 Nov 2002 20:01
Favicon

RE: UDP-encapsulated IPsec Transport mode


> -----Original Message-----
> From: Markus Stenberg [mailto:fingon <at> iki.fi]
> Sent: Wednesday, November 06, 2002 11:51 PM
> To: James Huang
> Cc: ipsec <at> lists.tislabs.com; 'l2tpext <at> ietf.org'
> Subject: Re: UDP-encapsulated IPsec Transport mode
> 
> 
> James Huang <james.huang <at> watchguard.com> writes:
> > Hi all,
> > 	In the appendix A of 
> draft-ietf-ipsec-udp-encaps-04.txt, there is
> > some discussions on the issue of multiple clients running 
> UDP-encapsulated
> > IPsec transport mode tunnels behind a NAT box.  However, I 
> did not find any
> > discussion on another related issue:  In the traffic 
> selector (ID) payload
> > the client sends out during quick mode exchange, should the 
> client use its
> > own private address or the public routable address (i.e. 
> the NAT box's
> > public IP address)?  If it the later, how does the client 
> know about that
> > public address?  This seems to be a serious issue, 
> especially for L2TP
> > voluntary tunnels secured by IPsec (in transport mode).
> 
> L2TP specific issues I am blissfully unaware of; however,
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Huang | 7 Nov 2002 20:01
Favicon

RE: UDP-encapsulated IPsec Transport mode


> -----Original Message-----
> From: Markus Stenberg [mailto:fingon <at> iki.fi]
> Sent: Wednesday, November 06, 2002 11:51 PM
> To: James Huang
> Cc: ipsec <at> lists.tislabs.com; 'l2tpext <at> ietf.org'
> Subject: Re: UDP-encapsulated IPsec Transport mode
> 
> 
> James Huang <james.huang <at> watchguard.com> writes:
> > Hi all,
> > 	In the appendix A of 
> draft-ietf-ipsec-udp-encaps-04.txt, there is
> > some discussions on the issue of multiple clients running 
> UDP-encapsulated
> > IPsec transport mode tunnels behind a NAT box.  However, I 
> did not find any
> > discussion on another related issue:  In the traffic 
> selector (ID) payload
> > the client sends out during quick mode exchange, should the 
> client use its
> > own private address or the public routable address (i.e. 
> the NAT box's
> > public IP address)?  If it the later, how does the client 
> know about that
> > public address?  This seems to be a serious issue, 
> especially for L2TP
> > voluntary tunnels secured by IPsec (in transport mode).
> 
> L2TP specific issues I am blissfully unaware of; however,
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 7 Nov 2002 21:11
Picon
Favicon

Note Well Statement


From time to time, especially just before a meeting, this statement is to
be sent to each and every IETF working group mailing list.
===========================================================================

				NOTE WELL

All statements related to the activities of the IETF and addressed to the
IETF are subject to all provisions of Section 10 of RFC 2026, which grants
to the IETF and its participants certain licenses and rights in such
statements.

Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which are
addressed to

    - the IETF plenary session,
    - any IETF working group or portion thereof,
    - the IESG, or any member thereof on behalf of the IESG,
    - the IAB or any member thereof on behalf of the IAB,
    - any IETF mailing list, including the IETF list itself,
      any working group or design team list, or any other list
      functioning under IETF auspices,
    - the RFC Editor or the Internet-Drafts function

Statements made outside of an IETF meeting, mailing list or other function,
that are clearly not intended to be input to an IETF activity, group or
function, are not subject to these provisions.
Permalink | Reply | 0 comments |
headers
Skip Booth | 8 Nov 2002 04:30
Picon
Favicon

RE: UDP-encapsulated IPsec Transport mode


James, does the recommendation in section 3.1.2 a) answer your question?  I
believe after fixing up the IP header to include the private address which was
advertised during the negotiation, the packet will pass through the SG filters.
The authors of this draft should be able to provide further clarification if
this doesn't address your concerns.

-Skip

On Thu, 7 Nov 2002, James Huang wrote:

>
>
> > -----Original Message-----
> > From: Markus Stenberg [mailto:fingon <at> iki.fi]
> > Sent: Wednesday, November 06, 2002 11:51 PM
> > To: James Huang
> > Cc: ipsec <at> lists.tislabs.com; 'l2tpext <at> ietf.org'
> > Subject: Re: UDP-encapsulated IPsec Transport mode
> >
> >
> > James Huang <james.huang <at> watchguard.com> writes:
> > > Hi all,
> > > 	In the appendix A of
> > draft-ietf-ipsec-udp-encaps-04.txt, there is
> > > some discussions on the issue of multiple clients running
> > UDP-encapsulated
> > > IPsec transport mode tunnels behind a NAT box.  However, I
> > did not find any
> > > discussion on another related issue:  In the traffic
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Huang | 8 Nov 2002 19:27
Favicon

RE: UDP-encapsulated IPsec Transport mode

Skip,
	If we fix up the source IP address using the private address
advertised in NAT-OA during IKE negotiation, then why should TCP/UDP
checksum be re-computed at the security gateway as was described in section
3.1.2?   The checksum was originally computed by the client using its
private address.  Also is this solution the same as the "built-in NAT"
solution mentioned in Appendix A of draft-ietf-ipsec-udp-encaps-04.txt to
solve the problem of multiple clients behind a NAT with overlapped traffic
specifications?

Thanks,
- James 

> -----Original Message-----
> From: Skip Booth [mailto:ebooth <at> cisco.com]
> Sent: Thursday, November 07, 2002 7:31 PM
> To: James Huang
> Cc: 'Markus Stenberg'; ipsec <at> lists.tislabs.com; 'l2tpext <at> ietf.org'
> Subject: RE: UDP-encapsulated IPsec Transport mode
> 
> 
> 
> James, does the recommendation in section 3.1.2 a) answer 
> your question?  I
> believe after fixing up the IP header to include the private 
> address which was
> advertised during the negotiation, the packet will pass 
> through the SG filters.
> The authors of this draft should be able to provide further 
> clarification if
(Continue reading)

Permalink | Reply | 0 comments |
headers
W. Mark Townsley | 8 Nov 2002 20:35
Picon
Favicon

l2tpext agenda for 55th IETF in Atlanta

Agenda Bashing
5 minutes

W. Mark Townsley
- WG Update
- L2TPv3 Status
15 minutes

Tom Mistretta
draft-l2tpext-infomsg-01.txt and
draft-nmcgill-l2tp-radius-ext-nas-port-00.txt
15 minutes

Rahul Aggarwal
draft-ietf-l2tpext-pwe3-ethernet-00.txt
10 minutes
Permalink | Reply | 0 comments |

Gmane