Re: [Dime] Review of draft-korhonen-dime-pmip6-03.txt

[<[e-mail]>]

Hi Hannes,

Further replies inline. I cut those parts away we already
resolved.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[e-mail]] 
> Sent: 10. elokuuta 2008 22:41
> To: Korhonen, Jouni /TeliaSonera Finland Oyj
> Cc: [e-mail]
> Subject: Re: [Dime] Review of draft-korhonen-dime-pmip6-03.txt

[snip]

> >> * I was also lacking sementic of the PMIP6-DHCP-Address AVP a bit.
> >> How does the information flow look like?
> >>     
> >
> >  The AAA may return a DHCP (4 or 6) server address to the MAG. THis
> >  would be useful in deployments where the MAG implements a 
> DHCP Relay.
> >  So the MAG receives the DHCP Server address over the MAG-AAA  
> >  interface,
> >  and uses the server address for *this* subscriber/realm 
> when relaying
> >  DHCP requests.
> >   
> I am just wondering why the AAA server controls which DHCP server is 
> contacted by the DHCP relay.
> Have you checked with the DHC folks to see what they think 
> about this idea?

It is for centralizing the configuration. Say, my MAGs serve +50
realms and each of those would have a different DHCP server. Now
if I need to make any change to server addressing (renumber existing,
add a new one or a remove one) I would need to configure all MAGs
one by one. We already do the same centralized management for LMAs
and HAs.

> >> *  MIP6-Agent-Info AVP
> >>
> >> The description currently does not provide enough information why  
> >> this
> >> AVP is needed.
> >> What happens when an entity receives this AVP?
> >> Why would one send it?
> >>     
> >
> >  This is one way of doing dynamic LMA discovery. So the AAA 
> knows which
> >  LMA to assign for the authenticating subscriber. MAG uses 
> >  it to figure
> >  out the LMA where to send subsequent PBUs..
> >
> >   
> Maybe we could provide this additional piece of information in the 
> document.

Ack.

[snip]

> >> The following text seems a bit fuzzy to me:
> >>
> >> "
> >>    The Diameter response messages MAY contain Framed-IPv6-Prefix  
> >> and/or
> >>    Framed-IPv4-Address AVPs.  For example a local Diameter proxy  
> >> MAY add
> >>    those in order to advertise locally available prefixes and  
> >> addresses
> >>    as well [16].  It is also possible that PMIPv6 mobility 
> support is
> >>    not allowed for a subscription.  In this case, a MAG may still
> >>    provide normal IP connectivity to the MN using, for 
> example, local
> >>    address pools.
> >> "
> >>
> >> What is the semantic of the Framed-IPv6-Prefix in 
> relationship to the
> >> other
> >> addresses being defined in this document?
> >>     
> >
> >  I am not sure if this is valid anymore but the originally 
> the reason
> >  was the following:
> >
> >  It was discussed whether it would make sense to allow PMIP-based  
> >  mobility
> >  for some prefixes and for some not. So the prefixes with mobility  
> >  would be
> >  signaled using PMIP specific AVPs where as prefixes without  
> >  mobility would
> >  use Framed-IPv6-Prefix AVPs. MAG/NAS could then treat prefixes  
> >  differently
> >  (note that how the MN would know the difference is not 
> solved yet..  
> >  there
> >  has been RA/RS based proposals around).
> >
> >   
> So, has the discussion concluded already?
> Where are these discussions taking place?

There was some discussion and I-Ds in NetLMM and later in the
unofficial NetExt bar BoF.

> >> * LMA-to-MAG
> >>
> >> The text at the beginning of the sentence is repeated again in  
> >> Section
> >> 6.2.
> >>
> >>
> >> You write:
> >>
> >> "
> >> The identity SHOULD be the same as
> >>    used on the MAG to HAAA interface, but in a case those 
> identities
> >>    differ the HAAA MUST have a mechanism of mapping the MN  
> >> identity used
> >>    on the MAG to HAAA interface to the identity used on 
> the LMA to  
> >> HAAA
> >>    interface.
> >> "
> >>
> >> In what cases are they different?
> >>     
> >
> >  One example.. the MN authenticates (over the MAG-AAA 
> interface) using
> >  some EAP-method that provides identity hiding. So the identity the
> >  MAG/NAS puts into the User-Name AVP for the access authentication
> >  could be then different from what gets used in a PBU as the MN-ID.
> >  The LMA would use the identity taken from the PBU MN-ID when  
> >  communicating
> >  with the AAA over the LMA-AAA interface. So the identities could  
> >  potentially
> >  be different and the AAA must be able to map them as one 
> internally  
> >  in that
> >  case. If some deployment uses the same identity in all 
> cases & places,
> >  fine.. but that must not restrict the flexibility of the AAA  
> >  interfaces.
> >   
> 
> That's an interesting issue with respect to security.

Could you enlighten me what issue?

> I have not followed the security discussions in NETLMM 
> regarding PMIPv6 
> but I recall that there was once a discussion whether the 
> security for 
> the PMIPv6 signaling is based on a MN-basis (similar to MIPv6) or 
> independent of the user.
>
> What is the discussion status?

I think what I had above is on slightly different topic. The
security in RFC5213 is between MAG and LMA, not per MN. If that
is what you are asking..

[snap]

Cheers,
	Jouni
_______________________________________________
DiME mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dime