Subject: RE: [Seamoby] CAR DiscoveryProtocol Requirements...

From: "Trossen Dirk (NRC/Boston)" <[email-masked]>
Date: Fri, 11 Jan 2002 12:42:36 -0500

Hi Hesham, 

some comments inline

> -----Original Message-----
> From: ext Hesham Soliman (ERA) [mailto:[email-masked]]
> Sent: Friday, January 11, 2002 11:42 AM
> To: Govind Krishnamurthi; [email-masked]
> Subject: RE: [Seamoby] CAR DiscoveryProtocol Requirements...
> 
> 
> Govind and all, 
> 
> Some comments below.
> 
> Generally I think it would be useful to identify
> which protocol these requirements apply to. 
> I.e. the protocol between the ARs or the one between
> the MN and the AR?
> 
> 
> 
>   > >
>   > >1. MUST translate L2 Ids (APs and ARs) to L3 Ids of ARs
>   > >
>   > >
>   > >2. MUST support L2 devices of different technologies
> 
> => What does this really mean ?

Having an AP in WLAN and Bluetooth and being able to discover
both.

> 
>   > >
>   > >6. Protocol applicability - SHOULD (show of hands 
>   > indicated that a MUST
>   > >is needed here) support inter-domain as well as 
> Intra-domain scope
>   > >
> 
> => Definitely a MUST IMO. Also we should be clear on the 
> meaning of 'domain'.

I agree with the MUST. Clarification of domain is certainly 
helpful.

> 
>   > >8. SHOULD minimize involvement of ARs which are not GAARs in CAR
>   > >discovery
> 
> => Going to Phil's comment, how do we measure a SHOULD ?
> What tradeoffs will be acceptable to exempt a solution
> from following this requirement? 
> I think it would be esaier to make it a MUST.

This minimization has to be seen compared to other protocols in
the first place. If there is a solution that does not at all involve
non-GAARs, the minimization is certainly optimized. The other
extreme would be a general flooding of the entire Internet to
resolve the L2 identifier. In between these extremes (including
them), the solutions will exist, and they have to be evaluated
against this requirement.

The SHOULD has been used since it wasn't clear if such kind of
evaluation for the selection of the final solution should be
mandatory or not. Personally, I prefer the MUST, too since I'd like
to see a final solution that minimizes involvement of non-GAARs.

> 
> I'd like to also suggest that if the WG still wants to
> keep section 4.1 of the problem statement draft, we 
> should at least change the wording in the first
> paragraph to reflect that the AR will _never_ 
> guarantee to know _all_ neighbouring ARs. 
> I think this is obvious. 

The wording in Section 4.1. doesn't imply that CAR guarantees
the knowledge of ALL GAARs. The wording has to be seen at the
point of TAR selection. For that, only the current status of 
knowledge regarding the GAARs is taken into account. 

It is obvious that CAR does not guarantee full knowledge, but it has 
at least to maximize the information regarding the GAARs with its
optimal
point of operation, i.e., the knowledge of all GAARs, though 
this optimal point might never be reached. But a solution that
at least enables to reach this point in a finite time is certainly
better than a mechanism that never reaches this point. Example
for the latter would be solution that were entirely be based on one
mobility management protocol. This solution could never 
discover GAARs that are using another mobility management protocol. 

> 
> Also 'anticipation' is misleading, because it is seems
> to imply that the MN does not signal. The MN can
> certainly anticipate and that is explained in the 
> low latency and FMIPv6 drafts referenced in the doc.

I don't see the problem of excluding MN signaling by using
the word 'anticipation'. Could you point out which wording
you don't like?

Regards,

Dirk

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "Trossen Dirk (NRC/Boston)" <[email-masked]>
Date: Fri, 11 Jan 2002 13:13:29 -0500

Hi Hesham,

comments inline

> 
> => To me the following text from the draft suggests
> that the AR knows ALL GAARs. I think that's unrealistic.
> 
>   4.1 Anticipated CAR Discovery
> 
>    In this approach, an AR currently serving the MN 
> identifies all CARs
>    for the MN's handoff, at some point prior to handoff.
> 
> 
>   > 
> => So we agree, then I suggest you reflect it in the text.

As I outlined in my mail, the identification of CARs at the AR
is bound the current knowledge of GAARs at the AR. Out of this
set of GAARs, all CARs are identified. The text does not imply that
all GAARs are known.

> => You\re making a lot of assumptions about the discovery
> mechanism. If a MN can hear RAs from different
> GAARs, it will discover them. If that is not 
> possible due to l2 limitations, there are ways to go
> around that, without depending on any mobility
> management protocol, but keeping in line with
> existing protocols. 
> I didn\t want to start arguing about solutions but
> I think it can be done.

I don't understand your point here since I don't see the 'many
assumptions'
that I make. I'm trying to address requirements to solve the
problem. This is to identify GAARs under the constraint to minimize
the ARs that are actually not GAARs of the considered AR. I don't care
about MN involvement or not. This is not prohibited by the current set
of requirements, and I agree, it shouldn't. You should look at the basic
text of the requirements.

> => anticipation should not be associated with the 
> case where the MN does not signal, you can have
> anticipation when the MN signals also. Therefore
> associating 'anticipation' with a certain model
> where the MN does not signal, does not seem right.
> 
> I'm referring to the title of ch 4.1

I would appreciate if you could point out WHICH wording does imply
that MN signalling is ruled out in the anticipated approach. It is 
certainly not the title. 

Regards,

Dirk

---

From: "Hemant Chaskar" <[email-masked]>
Date: Fri, 11 Jan 2002 22:06:25

Hi,

Be there RFC or not, this discussion is not based on the relevant issue in 
the first place. The issue raised is:

"can you make IKE create an SA between two nodes (one having a public 
address and another having a private address)?".

SA between public to private routers need not be done by direct IKE between 
public and private peers. In the case of public to private SA, SA can be 
created (say using IKE) between public router to border router of private 
router. Border router to private router SA can be taken for granted. There 
are various ways to do the latter including static configuration. Such a 
concatenation of two SAs will guarantee SA between public and private 
routers, which is what we want.

Hence, ability or otherwise of creating direct IKE between public and 
private is not at all the sumbling block behind the private address space 
requirement.

If there is any genuine stumbing block in this requirement, please let me 
know it.

Hemant

>From: Vijay Devarapalli <[email-masked]>
>To: "Hesham Soliman (ERA)" <[email-masked]>
>CC: [email-masked]
>Subject: Re: [Seamoby] CAR DiscoveryProtocol Requirements...
>Date: Fri, 11 Jan 2002 10:37:49 -0800
>
>"Hesham Soliman (ERA)" wrote:
> >
> > [reply for a very old mail]
> >
> >   > can you make IKE create an SA between two nodes (one having
> >   > a public address and another having a private address)?
> >
> > => Yes you can. There are IKE extensions for this.
>
>which RFC??
>
>---------------
>
>from Aboba's draft draft-ietf-ipsec-nat-reqts-00.txt
>
>c) Incompatibility between IKE address identifiers and NAT.
>    Where IP addresses are used as identifiers in IKE MM [7]
>    or QM, modification of the IP source or destination
>    addresses by NATs or reverse NATs will result in a
>    mismatch between the identifiers and the addresses in the
>    IP header. As described in [7], IKE implementations are
>    required to discard such packets.
>
>    In order to avoid use of IP addresses as IKE MM and QM identifiers,
>    userIDs and FQDNs can be used instead. Where user authentication
>    is desired, an ID type of ID_USER_FQDN can be used, as described in
>    [5]. Where machine authentication is desired, an ID type of ID_FQDN
>    can be used. In either case it is necessary to verify that the
>    proposed identity matches that enclosed in the certificate.
>    However, while use of USER_FQDN or FQDN identity types is possible
>    within IKE, there are usage scenarios (e.g. SPD entries
>    describing subnets) that cannot be accommodated this way.
>
>------------------
>
>However there are a couple of internet drafts in the IPSec WG
>dealing with this. Hopefully they will have a solution soon.
>
>If I am missing something, let me know.
>
>Vijay
>
>
> > I'm obviously not interested in anything involving
> > private addresses, but your point is incorrect.
> >
> > Hesham
>

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---

From: "Qiang Zhang" <[email-masked]>
Date: Fri, 11 Jan 2002 17:38:35 -0500

Hi, 

This sounds more an IPsec issue. In reality, it does happen that a public IP needs to IKE to a private IP behind a perimeter gateway, the private IP is non-routable unless NAT mapping is performed. 

The solution for sake of saving headache can be to introduce additional tunneling beneath the IKE, such as UDP encapsulation.

2 SAs can probably achieve a similiar effect in a lot scenarios, but unfortunately it also somewhat defeats the peer2peer purpose for certain usages.

Sorry if am actually off topic...

Qiang

Hemant

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Mon, 14 Jan 2002 15:11:01 +0100

> that MN signalling is ruled out in the anticipated approach. It is 

=> I already copied that part in the draft and put it in one
of my emails. 
If you missed it, it's the title (as I say above), and 
the first sentence.

Hesham