headers
Mohan Parthasarathy | 1 Jun 2005 03:28
Picon
Favicon

Re: issue 19 -- same addresses for both directions?


> 
> I wrote earlier tha the decision on issue 20 (who decides)
> also has a big impact on issue 19. If we had decided in 20
> that the decisions  are independent, then it might in fact
> have been very hard to  ensure that the two directions
> use the same addresses. As a result, allowing different
> addresses would make  more sense in this scenario.
> 
> But we ended up with "initiator decides". Therefore the
> deciding entity knows enough about the situation to be
> able to use the same address pairs in both directions.
> 
> Of course, this does not necessarily have to be done.
> We could develop a protocol that provides independent
> addresses, yet would be controlled by the initiator.
> (Probably with some cost in terms of complexity.
> And I'm not quite sure how to deal with NATs and
> keepalives in that kind of a scenario.)
> 
Hmm.. we chose the "initiator decides" option because it works
well with NAT. So, i am not sure i understand the issue here.
Here, the initiator finds two sets of addresses (one for
upstream and one for downstream traffic) and updates the
peer providing information about which address pair to be used
for downlink and which address to be used for up link.
I would assume that it is the initiator's responsibility for sending
keep alives. So, what is the issue here with NATs ? 

If the initiator is multi-homed and connected simultaneously to more
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Mikael Melen | 2 Jun 2005 07:49

Fwd: I-D ACTION:draft-nikander-esp-beet-mode-03.txt

----------  Forwarded Message  ----------

Subject: I-D ACTION:draft-nikander-esp-beet-mode-03.txt
Date: Wednesday 01 June 2005 23:03
From: Internet-Drafts <at> ietf.org
To: i-d-announce <at> ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
 directories.

 Title  : A Bound End-to-End Tunnel (BEET) mode for ESP
 Author(s) : P. Nikander, J. Melen
 Filename : draft-nikander-esp-beet-mode-03.txt
 Pages  : 29
 Date  : 2005-6-1

This document specifies a new mode, called Bound End-to-End Tunnel
   (BEET) mode, for IPsec ESP.  The new mode augments the existing ESP
   tunnel and transport modes.  For end-to-end tunnels, the new mode
   provides limited tunnel mode semantics without the regular tunnel
   mode overhead.  The mode is intended to support new uses of ESP,
   including mobility and multi-address multi-homing.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-03.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jari Arkko | 2 Jun 2005 08:17

FW: I-D ACTION:draft-nikander-esp-beet-mode-03.txt

FYI:
Internet-Drafts <at> ietf.org wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: A Bound End-to-End Tunnel (BEET) mode for ESP
>	Author(s)	: P. Nikander, J. Melen
>	Filename	: draft-nikander-esp-beet-mode-03.txt
>	Pages		: 29
>	Date		: 2005-6-1
>	
>This document specifies a new mode, called Bound End-to-End Tunnel
>   (BEET) mode, for IPsec ESP.  The new mode augments the existing ESP
>   tunnel and transport modes.  For end-to-end tunnels, the new mode
>   provides limited tunnel mode semantics without the regular tunnel
>   mode overhead.  The mode is intended to support new uses of ESP,
>   including mobility and multi-address multi-homing.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-03.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>i-d-announce-request <at> ietf.org 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 username
>"anonymous" and a password of your e-mail address. After logging in,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 2 Jun 2005 17:59
Picon

RE: issue 19 -- same addresses for both directions?

Mohan Parthasarathy wrote:

> If the initiator is multi-homed and connected simultaneously to 
> more than one access (e.g. UMTS and WLAN) at the same time, there
> might be some usefulness in having different paths for upstream 
> and downstream traffic though i don't know really what it is :-)  

I sort of agree with this: there might be some usefulness in this,
but I can't really give any good examples. 

Thus, I think we should follow the KISS principle and assume both 
directions use the same address pair. (If it turns out later that
there is some real important use for this, it can be added then.)

Best regards,
Pasi
Permalink | Reply | 2 comments |
headers
Jari Arkko | 2 Jun 2005 18:16

Re: issue 19 -- same addresses for both directions?

Pasi.Eronen <at> nokia.com wrote:

>(If it turns out later that
>there is some real important use for this, it can be added then.)
>  
>
This is a good observation. In some cases we make decisions
that cannot be easily reversed; in this case we are making a
limitation that could (or so it appears) be easily lifted when
in year N we want to use MOBIKE for something that requires
it. But I would personnally really like to do only the absolutely
necessary things right now, if not for other reason than the
ability to complete the RFC as soon as possible.

--Jari
Permalink | Reply | 0 comments |
headers
Mohan Parthasarathy | 2 Jun 2005 18:20
Picon
Favicon

Re: issue 19 -- same addresses for both directions?

Agreed.

mohan

----- Original Message ----- 
From: <Pasi.Eronen <at> nokia.com>
To: <mobike <at> machshav.com>
Sent: Thursday, June 02, 2005 8:59 AM
Subject: RE: [Mobike] issue 19 -- same addresses for both directions?

Mohan Parthasarathy wrote:

> If the initiator is multi-homed and connected simultaneously to 
> more than one access (e.g. UMTS and WLAN) at the same time, there
> might be some usefulness in having different paths for upstream 
> and downstream traffic though i don't know really what it is :-)  

I sort of agree with this: there might be some usefulness in this,
but I can't really give any good examples. 

Thus, I think we should follow the KISS principle and assume both 
directions use the same address pair. (If it turns out later that
there is some real important use for this, it can be added then.)

Best regards,
Pasi
_______________________________________________
Mobike mailing list
Mobike <at> machshav.com
https://www.machshav.com/mailman/listinfo.cgi/mobike
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tschofenig, Hannes | 3 Jun 2005 10:23
Picon

AW: issue 19 -- same addresses for both directions?

hi jari,  

we should use the same addresses in both directions. 
this seems to be much easier (from a protocol point of view and
regarding the traversal of nats/stateful packet filtering firewalls).  

ciao
hannes

> It looks to me that the decision on issue 20 (who decides)
> is the main determining factor issue 19 as well. If issue
> 20 resolution is that the initiator decides, then it more
> or less follows that we have same addresses in both
> directions. We can imagine different addresses even in
> this case, but it does not appear to be very useful or
> necessary.
> 
> On the other hand, if we decide in 20 that the decisions
> are independent, then it may in fact be very hard to
> ensure that the two directions use the same addresses.
> As a result, allowing different addresses would make
> more sense in this scenario.
> 
> My conclusion is that we should focus on trying to
> solve issue 20 first.
> 
> --Jari
> 
> 
> _______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Sommerfeld | 3 Jun 2005 20:42
Picon

Re: issue 19 -- same addresses for both directions?

On Sun, 2005-05-29 at 10:29, Jari Arkko wrote:
> Of course, this does not necessarily have to be done.
> We could develop a protocol that provides independent
> addresses, yet would be controlled by the initiator.

I haven't seen a compelling scenario which requires a different
address-pair in each direction.

That said, "initiator decides" effectively means "initiator tells
responder which addresses the responder should use when sending" and may
be silent about what the initiator does when sending -- unless we
require the reciever to reject traffic to/from the wrong address pair.

So I think, given our resolution to #20, #19 becomes almost a local
matter on the initiator.

					- Bill
Permalink | Reply | 0 comments |
headers
Francis Dupont | 8 Jun 2005 09:50
Picon
Picon

Re: issues 18, 15, 6 -- return routability

 In your previous mail you wrote:

   I think we came to agreement on when we can skip the test 
   completely (by default, do the check; fancier authorization
   is possible but does not have to be standardized). But what
   about the before/after moving the traffic part?

=> my opinion is the optional RR check SHOULD be done before but
the recommendation has to be relax (i.e., implementation choice)
when the previous address is known to no more work: there is a
trade-off between waiting for the RR check result and go immediately
to the new and working path.

Regards

Francis.Dupont <at> enst-bretagne.fr

PS: in an address set management framework, a no more working address
is simply removed from the set.
Permalink | Reply | 668 comments |
headers
Francis Dupont | 8 Jun 2005 10:08
Picon
Picon

Re: issue 3 - nats

 In your previous mail you wrote:

   Resolution:

    (a) Can we move behind a NAT?
          [Yes. But requires NAT-D payloads in the address change
          message, as discussed under issue 11.]

=> NAT-D or NAT-P (both detect NATs), see item j.

    (b) Can we move out from a NAT?
          [Yes. But see item h.]

    (c) To which extent do we support the case that
          party outside the NAT moves?
          [No. Outsider may not be able to initiate anything
          inside. The only exception is covered under
          item f.]

    (d) If we are behind a NAT, can peer have multiple
          addresses?
          [Yes.]

=> what is the real meaning of the question (NAT-T one side,
MOBIKE the other side?)

    (e) If we are behind a NAT on one interface, can
         another interface work without NAT/NAT-T?
         [Yes.]
(Continue reading)

Permalink | Reply | 0 comments |

Gmane