Subject: [Pana] PANA WG last call: draft-ietf-pana-ipsec-04.txt

From: Alper Yegin <[email-masked]>
Date: Mon, 01 Nov 2004 11:17:21 -0800

I reviewed this I-D, and couldn't find any technical issues.
There are few editorial comments I have. I'll forward them to the
editor.

Alper

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

---

From: Alper Yegin <[email-masked]>
Date: Tue, 02 Nov 2004 11:23:30 -0800

Hi Yoshi,

> 
> The two "SHOULD" in the above text are ambiguous.  I think when a
> Protection-Capability AVP is included in the PBR, a Device-Id AVP MUST
> be included in order to indicate the MAC or IP address of each EP.
> Also, when a Protection-Capability AVP is included, I think it is
> always true that the device identifier of each EP is either MAC or IP
> address.  On the other hand, when the PBR includes a Device-Id AVP, I
> think that the PaC MUST include a Device-Id AVP in the PBA.  In this
> case, what the PAA should do if the PAA sent a PBR with a
> Protection-Capability AVP and one or more Device-Id AVP but the PBA
> from the PaC does not contain any Device-Id AVP?  I think the right
> behavior for this case is that the PAA sends a PANA-Error-Request
> message with a PANA_MISSING_AVP result code and wait for a
> PANA-Error-Answer message to terminate the session.

I agree.

> 
> Suggested change:
> 
> "
>    The PANA-Bind-Request and the PANA-Bind-Answer message exchange is
>    also used for binding device identifiers of the PaC and EP(s), and
>    the IP address of the PAA to the PANA SA.  To achieve this, the
>    PANA-Bind-Request message MUST contain the device identifier(s) of
>    EP(s) in Device-Id AVP(s) when a Protection-Capability ASP is
>    included in the message.  

Do we use DI binding only when we use L2 or L3 ciphering enable after
PANA?

>    The PANA-Bind-Request message MUST also
>    contain the IP address of the PAA in an IP-Address AVP.  The
>    PANA-Bind-Answer message MUST contain the PaC's device identifier
>    in a Device-Id AVP when it is already presented with that of EP(s)
>    in the request with using the same type of device identifier as
>    contained in the request.  If the PANA-Bind-Answer message sent
>    from the PaC does not contain a Device-Id AVP with the same device
>    identifier type contained in the request, the PAA sends a
>    PANA-Error-Request message with a PANA_MISSING_AVP result code, and
>    wait for a PANA-Error-Answer message to terminate the session.
> "

...

> o Technical comment 4 (section 6.2)
> 
> "
>    Upon changing its point of attachment, a PaC that wants to quickly
>    resume its ongoing PANA session without running EAP MAY send its
>    unexpired PANA session identifier in its PANA-Start-Answer message.
>    Along with the Session-Id AVP, a MAC AVP MUST be included in this
>    message.  The MAC AVP is computed by using the PANA_MAC_KEY shared
>    between the PaC and its previous PAA that has an unexpired PANA
>    session with the PaC.  This action signals PaC's desire to perform
>    the mobility optimization.  In the absence of a Session-Id AVP in
>    this message, the PANA session takes its usual course (i.e.,
>    EAP-based authentication is performed).
> "
> 
> Since MAC for the PSR used for mobility handling is calculated by
> using a different key other than the PANA_MAC_KEY that is to be
> established between the PaC and the current PAA and used for
> subsequent PANA messages, I would suggest using a separate AVP
> (something like Mobility-Optimization-MAC AVP or Mobility-Token AVP )
> for this special MAC carried in PSR rather than overloading the MAC
> AVP to be used with different keys, in order to avoid possible
> mis-implementation.

The computed MAC and the PSA message are verified by the previous PAA.
So, the key used for verification is PANA_MAC_KEY with previous PAA. I
see this aligned with what we have for normal operation (when you look
at from previous PAA perspective). The only important detail is, the
received PSA is not authenticated by the current PAA, but by the
previous PAA. 

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 Nov 2004 08:23:55 -0500

Hi Mohan,

Thank you for your last call comments.  Please see my comments below.

On Sun, Sep 26, 2004 at 05:54:00PM -0700, Mohan Parthasarathy wrote:
> The document seems to be in a good shape and here are a few comments that i had.
> 
> 1) In section 2.0,
>       PANA Session:
> 
>           A PANA session begins with the handshake between the PANA Client
>           (PaC) and the PANA Authentication Agent (PAA), and terminates as a
>           result of an authentication failure, a timeout, or an explicit
>           termination message.  A fixed session identifier is maintained
>           throughout a session.  A session cannot be shared across multiple
>           network interfaces.
> 
>      Can we explain the reason why the session cannot be shared across multiple network interfaces ?
>       I could not find any other place in the document where this is explained (perhaps missed it).

This is because only one device-identifier of the PaC is allowed to be
bound to a PANA sesson at a time for simplicity.  We can add some
explicit text on this.

> 
> 2) In section 4.1,
> 
>       In any case, PANA MUST NOT generate an EAP message on behalf of EAP
>       peer or EAP (pass-through) authenticator.
> 
>    This looked like a general statement and not specific section to 4.1. It might have been
>    good to have a general section on how EAP maps to PANA or at least how PANA uses
>    EAP.

I think that "PANA MUST NOT generate an EAP message" is obvious
because PANA is defined as an EAP transport protocol, not defined as
part of or an extention to EAP.  Can we simply remove the sentense in
section 4.1.?  BTW, PANA state machine draft describes how EAP maps to
PANA.

> 
> 3) In section 4.1,
> 
>       A Nonce AVP MUST be included in PANA-Start-Request and
>       PANA-Start-Answer messages.  The nonces are used to establish a PANA
>       SA.
> 
>     This is the first place Nonce is used but not defined/explained at to why nonce
>      is needed ? I understand that it adds freshness to the key material used for PANA
>      SA. But isn't that already taken care when AAA-key is derived.
>      It might be good to point out the security property of using the
>      Nonce in the PANA_MAC_KEY.

draft-ietf-eap-keying-03.txt states:

"
[3]  Generation of fresh transient session keys (TSKs).  The Secure
     Association Protocol typically guarantees the freshness of session
     keys by exchanging nonces between both parties and then mixing the
     nonces with the AAA-Key in order to generate fresh unicast (phase
     2a) and multicast (phase 2b) session keys.  By not using the AAA-
     Key directly to protect data, the secure Association Protocol
     protects against compromise of the AAA-Key, and by guaranteeing the
     freshness of transient session keys, assures that they are not
     reused.
"

It seems to me that PANA_MAC_KEY is a TSK used only for PANA and the
usage of nonces for deriving PANA_MAC_KEY is aligned with the EAP
keying draft.  We can add some clarification text on this.

> 
> 4) Section 4.3 Authorization phase :
>         I am confused by the usage of word "Authorization". In the "Authentication phase",
>         the PaC is in the process of getting authenticated. Similarly does it mean that the PaC
>         is in the process of getting authorized ? So, if i send a PANA_SUCCESS at the end
>         of authentication phase, by definition the node is both authenticated and authorized. So,
>         i don't know what authorization phase means.

I agree that more appropriate naming would be needed for the phase.

> 
> 5) section 4.3 : It is not explained as to how the replay attack is prevented. The attacker can
>     collect the ping answers and can bombard them. But the use of sequence numbers prevent
>     the replay attack. 

I agree.  We can add some text on replay attack protection perhaps in 
security considerations section?

Also, if there was a recent request/response exchange, that implies that
>     the other side is alive because of the sequence number being acked. This can be used 
>     as an optimization to not send the ping request.

Yes, we can have explicit text in section 11.8 something like: "Not
only a PANA ping exchange but also other valid recent request/answer
exchange can imply the other side is alive."  And this would also be a
resolution to your comment 8) below.

> 
> 6) In section 5.3, 
> 
>     When a request message is received, it is considered valid in terms
>     of sequence numbers if and only if its sequence number matches the
>     expected value.  This check does not apply to PANA-PAA-Discover, and
>     the very first request messages.
> 
>    Expand "the very first request messages". 

How about this?

"... the messages exchanged in the discovery and handshake phase,
i.e., PANA-PAA-Discover, PANA-Start-Request and PANA-Start-Answer
messages."

> 
> 7) In section 7.3,
> 
>      Vendor-Id
> 
>       The Vendor-Id field is present if the 'V' bit is set in the AVP
>       Flags field.  The optional four-octet Vendor-Id field contains the
>       IANA assigned "SMI Network Management Private Enterprise Codes"
>       [ianaweb] value, encoded in network byte order.  Any vendor
>       wishing to implement a vendor-specific PANA AVP MUST use their own
>       Vendor-Id along with their privately managed AVP address space,
>       guaranteeing that they will not collide with any other vendor's
>       vendor-specific AVP(s), nor with future IETF applications.
> 
> I don't know why the privately managed AVP address space cannot overlap with
> some other vendor specific AVPs ? Section 10.4.1 does not say anything.

Section 10.4.1 have explicit text:

"
Vendors can have their own AVP Codes namespace
   which will be identified by their Vendor-ID (also known as
   Enterprise-Number) and they control the assignments of their
   vendor-specific AVP codes within their own namespace.  
"

Isn't the above text enough to state that the privately managed AVP
address space cannot overlap with some other vendor specific AVP?

> 
> 8)  In section 11.1, you can note that the sequence number also can be used as liveness
>      check.

Please see my comment on your comment 5).

> 
> Editorial
> --------
> 1) In section 4.1,
>     A PANA-Start-Request message MAY carry a Cookie AVP that contains a
>    cookie.  The sequence number is set to a randomly picked initial
>    sequence number.  The cookie is used for preventing the PAA from
>    resource consumption DoS attacks by blind attackers.  
> 
>     s/blind attackers/attackers.
> 

OK.

> 2) Section 11.8,
> 
>        11.8  Livenes Test
> 
>     s/Livenes Test/ Liveness Test

OK.

> -mohan

---

From: Alper Yegin <[email-masked]>
Date: Tue, 02 Nov 2004 12:36:46 -0800

Hi Mohan,

>           (PaC) and the PANA Authentication Agent (PAA), and
terminates as
> a

If you find this too limiting, I guess it can be removed. But otherwise
the objective is to iterate that PANA state/session is per-interface.
For example, you cannot run PANA on one interface and expect the
multi-interfaced host to be able to connect to access network on all
interfaces. Obvious, but we thought worth mentioning...

...

>         the PaC is in the process of getting authenticated. Similarly
does
> it mean that the PaC

Hmmmm. Maybe we should call this "authorized phase". There is really no
PANA "action" that changes the session in this phase. Does this make
sense, or does anyone have another suggestion? 
...

> I don't know why the privately managed AVP address space cannot
overlap
> with

The text means Vendor_ID+vendor_AVP_space does not collide with others'.
That makes sense when you read it like this ("they" is referring to this
combination). The text is copied from Diameter spec.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 Nov 2004 11:23:27 -0500

Hi Alper,

> Do we use DI binding only when we use L2 or L3 ciphering enable after

DI binding is needed regardless of L2 or L3 ciphering is used.  DI
binding is performed either cryptographically or
non-cryptographically.  

Non-cryptographic DI binding does not need Device-Id AVPs to be
carried in PANA message, as the DI information can be just taken from
the MAC/IP headers or physical/logical port numbers.

Cryptographic DI binding needs Device-Id AVP to be carried in PANA
messages with MAC AVPs, which requires a PANA SA that is always needed
to enable L2 or L3 ciphering after PANA.  (This also implies that when
a Protection-Capability AVP is carried in PBR, it comes with a MAC
AVP.)

On the other hand, it is possible to establish a PANA SA even when L2
or L3 ciphering is NOT enabled after PANA.  In this case, it is
possible to perform cryptographic DI binding.  However, I think this
is useless because the bound DI is not cryptographically tied with
subsequent data traffic ciphering.

> received PSA is not authenticated by the current PAA, but by the

That difference (i.e., the previous PAA is the actual verifier of the
MAC in PSA) came up with my comment...  What do others think?

Regards,
Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 3 Oct 2004 18:17:56 -0700

Yoshihiro,

Thanks for your comments.

> My last call comments on draft-ietf-pana-ipsec-04.txt are available at
> http://www.toshiba.com/tari/pana/draft-ietf-pana-ipsec-04_ohba-comments.txt.
> Most are editorial comments.  There are three technical comments which
> are shown below:
> 
> Technical comment 1 (on section 6):
> 
> "
>            ID_KEY_ID data = (Session-Id | Key-Id)
> 
>    The Session-Id and Key-Id are the values contained in the data
>    portion of the Session-Id and Key-Id AVP respectively [PANA-PROT].
>    They are concatenated to form the content of ID_KEY_ID data. IP
>    addresses cannot be used as identifier as the PaC may be re-
>    authenticated multiple times and hence may not uniquely identify the
>    pre-shared key.
> "
> $ohba(technical) I don't think the reason for why not using an IP
> address of the PaC in ID_KEY_ID is because the PaC may be
> *re-authenticated multiple times*.  The actual reason is that the same
> PaC or a different PaC may use the same IP address *across a PANA
> session*, e.g.,
> 
> PaC A acquires IP address X and establishes a PANA session.  After the
> PANA session terminates for some reason, the same PaC A or another PaC
> B acquires IP address X and establishes a new PANA session.  In this
> case, if ID_KEY_ID data were defined as (PaC's IP address | Key-Id),
> it would end up with having the same ID_KEY_ID for the two IKE
> pre-shared keys derived from two different PANA sessions.
> 

> Technical comment 2 (on Appendix A):
> 
> "
>         When [RFC3456] is used, DHCP is
>         run over the IPsec tunnel and the address (IPsec-TIA) is
>         assigned to the IPsec tunnel interface.
> "
> 
> $ohba(technical) I am not sure RFC3456 assumes that IPsec tunnel mode
> SA is always implemented as a logical IP interface.  Please check.
> (If IPsec tunnel mode SA does not have to be implemented as a logical
> IP interface, I think the same source address selection could exist.)
> 
In section 3.1 of RFC 3456,

   Since the security parameters used for different SAs are based on the
   unique requirements of the remote host and the security gateway, they
   are not described in this document.  The mechanisms described here
   work best when the VPN is implemented using a virtual interface.

And in lot of other places, it uses the phrase "IPsec tunnel mode interface".

> Technical comment 3 (on Appendix A):
> 
> "
>         The link-local address
>         (IPsec-TOA) is assigned to the physical interface. As there is
> "
> 
> $ohba(technical) Why the IPsec-TOA needs to be a link-local address in
> RFC3456?  It could be a non-link-local address, I think.
> 
In the framework document, we use a "SHOULD" for using link-local address
as IPsec-TOA i think.  I agree that it could be a non-link-local address also.
I don't think the draft dis-allows that. Perhaps, we can clarify that in the draft.

-mohan

> Best regards,
> 
> Yoshihiro Ohba
> 
> 
> On Wed, Oct 20, 2004 at 04:49:11PM -0700, Alper Yegin wrote:
> > 
> > This message announces the PANA WG last call on "PANA Enabling
> > IPsec-based Access Control" document (draft-ietf-pana-ipsec-04.txt). The
> > last call will conclude on Nov 3rd, 2004.
> > 
> > Please read and review the document, and register your feedback on the
> > PANA mailing list (even if it is a simple "I read the document and it is
> > ready to proceed.").
> > 
> > http://www.ietf.org/internet-drafts/draft-ietf-pana-ipsec-04.txt
> > 
> > Previously discussed and closed issues on this document can be found at:
> > http://danforsberg.info:8080/pana-issues/
> > 
> > - PANA WG Chairs
> > 
> > 
> >

---

From: Alper Yegin <[email-masked]>
Date: Tue, 02 Nov 2004 19:27:05 -0800

Yoshi,

> binding is performed either cryptographically or

OK, but your text is implying otherwise. Since no alternative is
presented, it sounds like DI is included "only when" Prot-Cap is
included.

> MAC in PSA) came up with my comment...  

The text says:

   The MAC AVP
   can only be verified by the previous PAA, therefore a copy of the
   PANA message SHOULD be provided to the previous PAA.

> What do others think?

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 Nov 2004 11:44:01 -0500

>    work best when the VPN is implemented using a virtual interface.

OK, Then it might be better to insert "typically" like:

"
     When [RFC3456] is used, DHCP is run over the IPsec tunnel and the
     address (IPsec-TIA) is typically assigned to the IPsec tunnel
     interface.
"

> as IPsec-TOA i think.  

I checked the framework draft and I could not find such "SHOULD" for
using link-local address as IPsec-TOA in IPv4.  Since RFC 3456 is
defined for IPv4, I think the original text in Appendix A is correct 
only when IPv4 link-local address is used as the PRPA.

By the way, in the case of IPv6, we can say that the link-local
address SHOULD be used as IPsec-TOA, according to the following text
in the framework draft:

"
   3.  In IPv6, clients configure a link-local address [RFC2462] when
      they initialize an interface.  This address SHOULD be used as a
      PRPA.
"

AND

"
   2.  If the network uses IPsec for protecting the traffic on the link
      subsequent to PANA authentication [I-D.ietf-pana-ipsec], the PaC
      would use the PRPA as the outer address of IPsec tunnel mode SA
      (IPsec-TOA).
"

Yoshihiro Ohba

> I agree that it could be a non-link-local address also.

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 4 Oct 2004 10:26:29 -0700

had.
> bound to a PANA sesson at a time for simplicity.  We can add some
Some explicit text would help the reader why such a design choice was made.

> section 4.1.?  BTW, PANA state machine draft describes how EAP maps to
That is fine by me. 

> keying draft.  We can add some clarification text on this.
Interesting. I never thought of it as TSK. The secure association protocol here
is the exchange of nonces in the beginning. Can we clarify this in the document ?

> I agree that more appropriate naming would be needed for the phase.
I am okay with the word "Authorized phase".

> security considerations section?
Ok.
> resolution to your comment 8) below.
Yes.

> i.e., PANA-PAA-Discover, PANA-Start-Request and PANA-Start-Answer
Fine.

> address space cannot overlap with some other vendor specific AVP?
I guess my confusion is that if the vendor ID is unique, why can't the
vendor-specific AVP can't overlap ?

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 4 Oct 2004 10:36:52 -0700

> interfaces. Obvious, but we thought worth mentioning...
It is still not obvious to me :-) Who is being authenticated ? Why does
the interface matter ? What if i have replicated interfaces i.e, 2 interfaces
attached to the same link (RFC 2461 terminology) ? The secure association
protocol is the phase where the IP address or MAC address (that is related
to the interface) comes into the picture. So, how does it matter to PANA itself ?

> sense, or does anyone have another suggestion? 
Authorized phase is fine by me.

> combination). The text is copied from Diameter spec.
The wording can still be fixed i guess.

-mohan

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 03 Nov 2004 18:55:06 +0100

Hi all, here you have my comments about pana draft 06 (sorry if some of
them has been just explained)

section 4.1:

--Cookie value is calculated as Cookie = <secret-version> | HMAC_SHA1(
<Device-Id of PaC> , <secret> )

Device-Id is not included during in PDI and PSA/PSR negotitation. Thus
this value cannot be extracted. I think it could be PaC's PRPA. In fact
in next paragraphs no explanation about Device-Id field in the cookie
generation.

--"Initial EAP Request MAY be optionally carried by the
PANA-Start-Request (as opposed to by a later PANA-Auth-Request) message
in order to reduce the number of round-trips. ---->This optimization
SHOULD NOT be used if the PAA discovery is desired to be
stateless.<------ " I think it should be expanded or at least a
reference where it is explained.

Section 4.2
-- I think some kind of clarification should be done why EAP carried by
PAN optimization could be not always required. I mean advantage why
no-optimization could be useful.

--"...the IP address of the PAA to the PANA SA. To achieve this, the
PANA-Bind-Request SHOULD contain the device identifier(s) of the EP(s)
in Device-Id AVP(s) when they are either MAC or IP address(es)"

When PAA is co-located with EP, is EP-Device-Id sent? I think YES
because it does not specify the contrary.

--" PaC MUST include a PPAC AVP in order to indicate its choice of
method when there is a match between the methods offered by the PAA and
the methods available on the PaC. When there is no match, a PPAC AVP
MUST NOT be included and the Result-Code AVP MUST be set to
PANA_PPAC_CAPABILITY_UNSUPPORTED in the PANA-Bind-Answer message."

What happens after that? Retransmission? Session finished? I think Under
PaC point of view session should be finished.

-- "When this occurs, the PAA MUST send PANA-Bind-Request with a result
code PANA_AUTHORIZATION_REJECTED. If a AAA-Key is established between
PaC and PAA by the time when the EAP-Success is generated by the EAP
server (this is the case when the EAP method provides protected success
indication), this PANA-Bind message exchange MUST be protected with a
MAC AVP and with carrying a Key-Id AVP. The AAA-Key and the PANA session
MUST be deleted after the PANA-Bind message exchange".

Would it make sense finish the session by using a traditional PTR/PTA
exchange?

Section 4.4.

-- "If PAA cannot identify the session, it MUST respond with a
PANA-Error-Request with the error code PANA_UNKNOWN_SESSION_ID.
PANA-Reauth-Request/Answer messages MUST contain a MAC AVP when PANA SA
is available. "

Taking into account section 5.7 PaC should restransmit
PANA-Reauth-Request but however I think same answer would be received
becuase this error cannot be solved. On the other hand I think PAA
should initiate reauthentication.

-- BTW in figure 7:

<----- PANA-Auth-Request(p) [Session-Id, EAP{Request}, MAC]
--X--> PANA-Auth-Answer(p) // No piggybacking EAP-Response [Session-Id,
MAC]
-----> PANA-Auth-Request(q+1)

What would happen if PANA-Auth-Answer(p) is losted ? could
PANA-Auth-Request(q+1) be used to confirm PANA-Auth-Reques(q)?

I think this situation could happen in another situation . For example
Could PANA-Ping-Request be confirmed(PANA-Ping-Answer is lost) by
another PANA message that is possible in the authorized state ?

-- Section 5.1 page 20

"IP-Address AVP: contains an IP Address of a PaC. "

or PAA

-- Section 5.3

"PaC and PAA maintain two sequence numbers: the next one to be used for
a request it initiates and the next one it expects to see in a request
from the other end. These sequence numbers are 32-bit unsigned numbers.
They are monotonically incremented by 1 as new requests are generated
and received..." <--- I guess "respectively"

Reading this section I have a doubt taking into account this exchange:

PaC PAA
<-----req(x)------------
x+1 (...incremented by 1 as new requests are generated and received..)
------ans(x)--(losted)-->

<------req(x)------------
"When a request message is received, it is considered valid in terms of
sequence numbers if and only if its sequence number matches the expected
value." ---> Taking into account this text, second req(x) would not be
considered valid though maybe I am missing something.

I know it should be retransmitted but maybe this text is bit confused...

-- Section 5.6 (page 24)

In the PANA Session attributes:

* Device-Id of PaC
* IP address of PaC (may be the same as the Device-Id of PaC)

if Device-Id AVP is an IP address ... could IP address of PaC be different?

--section 5.8

"When IPsec-based security [I-D.ietf-pana-ipsec] is the choice of access
control, the PAA SHOULD provide IP address(es) as EP(s)' device ID, and
expect the PaC to provide its IP address in return. In case IPsec is not
used, ---->MAC addresses are used as device IDs when available<-----*.
If non-IPsec access control is enabled, and a MAC address is not
available, device ID exchange does not occur within PANA. Instead, peers
rely on lower-layers to provide locally-significant identifiers along
with received PANA packets. "

* is it really needed this restriction? why don't we could use IP
address as Device Id though no IPSec is used.
-- Section 6.2

"As part of the context transfer, an intermediate AAA-Key material is
provided by the previous PAA to the current PAA. AAA-Key-int = The first
N bits of HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) The value of
N depends on the integrity protection algorithm in use, i.e., N=160 for
HMAC-SHA1. ---->DiameterIdentity is the identifier of the current
PAA<----*. Session-ID is the identifier of the PaC's PANA session with
the previous PAA."

With respect to Julien's comment: I think here there is a confusion. I
think current PAA is also new PAA in the sense that PaC is trying to
connect to new PAA that is the current (where PaC is now placed). Thus
there is a contradiction with respect to PANA-CTP draft I think.

-- Section 11.9

"An operator can reduce the risk exposure by forcing the PaC to perform
an EAP-based authentication immediately after the PaC gains access to
new link via the ----> optimized PANA execution.<-----" expand that or
reference to corresponding section

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 4 Oct 2004 10:58:24 -0700

Ok.

> only when IPv4 link-local address is used as the PRPA.
You are right. When i answered, i did not realize that we are discussing
IPv4 here.  I am a bit confused now. Which original text you are referring
to here ? There are too many emails suddenly :-)

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 4 Oct 2004 11:07:35 -0700

Yoshi,

 > 
> o Technical comment 1 (section 4.2)
> 
> "
>    PANA-Bind-Request SHOULD contain the device identifier(s) of the
>    EP(s) in Device-Id AVP(s) when they are either MAC or IP address(es),
>    and the IP address of the PAA in an IP-Address AVP.  PANA-Bind-Answer
>    SHOULD contain PaC's device identifier in a Device-Id AVP when it is
>    already presented with that of EP(s).  The PaC MUST use the same type
>    of device identifier as contained in the PANA-Bind-Request message.
> "
> 
>    included in the message.  The PANA-Bind-Request message MUST also
In the case of IPsec, the device identifier is not know until the IKE is run. So, during
the PBR/PBA exchange the right device identifier is not known, right ? How can
the PaC include the device identifier in that case ?

-thanks
mohan

> 
> o Technical comment 2 (section 4.2)
> 
> "
>    The PANA-Bind-Request message MAY also contain a
>    Protection-Capability AVP to indicate if link-layer or network-layer
>    ciphering should be initiated after PANA.  
> "
> 
> If the Result-Code AVP included in the PBR does not indicate
> PANA_SUCCESS, I think a Protection-Capability AVP does not need to be
> included (or SHOULD NOT be included, to avoid unnecessary information
> disclosure to unauthorized clients) in the PBR and the corresponding
> PBA.
> 
> Suggested change:
> 
> "
>    The PANA-Bind-Request message with a PANA_SUCCESS result code MAY
>    also contain a Protection-Capability AVP to indicate if link-layer
>    or network-layer ciphering should be initiated after PANA.
> "
> 
> 
> o Technical comment 3 (section 4.2)
> 
> "
>    Additionally, PANA-Bind-Request MUST include a
>    Post-PANA-Address-Configuration AVP, which helps PAA to inform PaC
>    about whether a new IP address MUST be configured and the available
>    methods to do so.  PaC MUST include a PPAC AVP in order to indicate
>    its choice of method when there is a match between the methods
>    offered by the PAA and the methods available on the PaC.
> "
> 
> If the Result-Code AVP included in the PBR does not indicate
> PANA_SUCCESS, I think a PPAC AVP does not need to be included (or
> SHOULD NOT be included, to avoid unnecessary information disclosure to
> unauthorized clients) in the PBR and the corresponding PBA.  Also
> there is some duplicated wording "PaC MUST include a PPAC AVP in order
> to indicate" text in the text.
> 
> Suggested change:
> 
> "
>    Additionally, the PANA-Bind-Request message with a PANA_SUCCESS
>    result code MUST include a Post-PANA-Address-Configuration AVP,
>    which helps the PAA to inform the PaC about whether a new IP
>    address MUST be configured and the available methods to do so.  The
>    PaC MUST include a PPAC AVP in the PANA-Bind-Answer message in
>    order to indicate its choice of method when there is a match
>    between the methods offered by the PAA and the methods available on
>    the PaC.
> "
>

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 Nov 2004 16:02:34 -0500

> to here ? There are too many emails suddenly :-)

I am referring to the following text in Appendix A:

"
        When [RFC3456] is used, DHCP is
        run over the IPsec tunnel and the address (IPsec-TIA) is
        assigned to the IPsec tunnel interface. The link-local address
        (IPsec-TOA) is assigned to the physical interface. 
"

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 Nov 2004 17:26:14 -0500

OK.

OK.

> I am okay with the word "Authorized phase".

I am okay with the word "Authorized phase", too.

> vendor-specific AVP can't overlap ?

Because a vendor-specific AVP is identified with the Vendor ID plus
AVP Code (not identified solely with AVP Code).

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 04 Nov 2004 01:51:08 +0100

Hi all ,  I have only a technical question about this draft:

"
   When PAA and EP are 
   not co-located, any traffic destined to PAA is forwarded to PAA after 
   decrementing the TTL in the IP header. PAA would drop the packet if 
   the TTL is not 255. PaC also would drop the packets coming from PAA 
   if the TTL is not 255.
"
----> I was wondering how PaC could receive a IP packet with TTL != 255 
in the non-colocated case I think PAA would send traffic directly to PaC 
without passing through EP/AR.

"
 Hence, we need the following explicit SPD 
   entry on PaC and EP for bypassing IPsec protection for PANA traffic. 
    
      If source_port = PANA_PORT OR dest_port = PANA_PORT 
          THEN BYPASS

"
I think in the non-colated case this rule only makes sense in the PaC. 
If this one is applied in the PaC side, PANA protocol is not 
encapsulated in the IPSec tunnel between PaC and EP. In that case I 
think PANA packets would go directly to PAA and EP does not take part in 
this traffic. The same happens with the traffic from PAA to PaC.

On the other hand, if this rule remains in the PaC for all cases 
(co-located and non-colocated) EP should include this rule in co-located 
case also. But the reason I don't think it is the TTL value becuase 
there is still only one hop.

Maybe I am missing something.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 Nov 2004 18:05:00 -0500

> presented, it sounds like DI is included "only when" Prot-Cap is

OK.  Then how about adding some text on taking DI from MAC/IP headers
when Protection-Capability AVP (and Device-Id AVP) is not included in
PBR?

> > subsequent data traffic ciphering.

..

>    PANA message SHOULD be provided to the previous PAA.

OK.  Maybe whether using the MAC AVP or defining yet another "MAC" AVP
for this mobility handling case is just a matter of preference.  So I
can withdraw my comment unless someone has the same flavor as me.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 Nov 2004 17:46:40 -0500

> the PaC include the device identifier in that case ?

I don't understand this.  When IPsec is used, the device identifier is 
IPsec-TOA, which is PRPA that stays the same before and after PANA
authentication, isn't it?

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 02 Nov 2004 19:03:42 -0500

Hi Rafa,

Thank you for sending detailed comments.  I try to answer to your comments 
for the part I can answer.  Please see below.

> in next paragraphs no explanation about Device-Id field in the cookie

DI can be extracted from MAC/IP header of PANA messages.  We can add some 
text to clarify this.

How about this?

"
   Initial EAP Request MAY be optionally carried by the
   PANA-Start-Request (as opposed to by a later PANA-Auth-Request)
   message in order to reduce the number of round-trips.  This
   optimization SHOULD NOT be used if the PAA discovery is desired to be
   stateless since transmission of an EAP request creates state at EAP
   layer [I-D.ietf-eap-statemachine].
"

> no-optimization could be useful.

How about changing from:

"
   The main task in authentication phase is to carry EAP messages
   between the PaC and the PAA.  EAP Request and Response messages are
   carried in PANA-Auth-Request messages.  PANA-Auth-Answer messages are
   simply used to acknowledge receipt of the requests.  As an
   optimization, a PANA-Auth-Answer message MAY include the EAP
   Response.  Another optimization allows optionally carrying the first
   EAP Request/Response in PANA-Start-Request/Answer message as
   described in Section 4.1
"

to:

"

   The main task in authentication phase is to carry EAP messages
   between the PaC and the PAA.  EAP Request and Response messages are
   carried in PANA-Auth-Request messages.  PANA-Auth-Answer messages are
   simply used to acknowledge receipt of the requests.  As an
   optimization, a PANA-Auth-Answer message MAY include the EAP
   Response.  This optimization MAY not be used when it takes time to generate 
   the EAP-Response (due to, e.g., intervention of human input), in
   which case returning an EAP-Auth-Anser message without piggybacking an
   EAP-Response can avoid unnecessary retransmission of the
   PANA-Auth-Request message.  Another optimization allows optionally
   carrying the first EAP Request/Response in PANA-Start-Request/Answer 
   message as described in Section 4.1.
"

Yes.

> PaC point of view session should be finished.

Yes, it should be finished.

> Would it make sense finish the session by using a traditional PTR/PTA

Since PTR/PTA does not contain a Key-Id AVP, you cannot use PTR/PTA to
derive PAMA_MAC_KEY and then immediately terminate the session.

> should initiate reauthentication.

When the PAA returns the PER with the error code
PANA_UNKNOWN_SESSION_ID, it should terminate the session once it
receives a PEA. After that, subsequent PANA-Reauth-Request will not be
answered.  

How about the following change?

"
   If PAA cannot identify the session, it MUST respond with a
   PANA-Error-Request with the error code PANA_UNKNOWN_SESSION_ID and
   terminate the session once it receives a PANA-Error-Answer for the
   request.
"

> PANA-Auth-Request(q+1) be used to confirm PANA-Auth-Reques(q)?

This is a good point.  Since the PANA-Auth-Request(q+1) would not have
been generated if the PANA-Auth-Answer(p) were not sent, I think it is
logical to use the PANA-Auth-Request(q+1) as an acknowledgement for
PANA-Auth-Request(p).

> another PANA message that is possible in the authorized state ?

In this case, there is not tight relationship betwen PANA-Ping-Answer
and other type of PANA request, I think we cannot use other type of
PANA request as an acknowledgement for PANA-Ping-Request.

OK.

OK.

> I know it should be retransmitted but maybe this text is bit confused...

Just be aware that the above text does not say anything about what the
receiver should do if the messesage is considered invalid.

The second req(x) is invalid by definition in terms of sequence
number.  And we have explicit text in the same section on how to 
deal with the dup:

"
   PaC and PAA MUST respond to duplicate requests.  Last transmitted
   PANA answer MAY be cached in case it is not received by the peer and
   that generates a retransmission of the last request.  When available,
   a cached answer can be used instead of fully processing the
   retransmitted request and forming a new answer from scratch.
"

So I think the current text is clear enough.

> if Device-Id AVP is an IP address ... could IP address of PaC be different?

If Device-Id AVP is an IP address it is the same as IP address of PaC.
So how about this?

"
 * IP address of PaC (the same as the Device-Id of PaC when IP
address is used as the device identifier)
"

> reference to corresponding section

I think the text should be:

"
An operator can reduce the risk exposure by
forcing the PaC to enter a re-authentication phase immediately
after the PaC gains access to new link.
"

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 04 Nov 2004 18:09:38 +0100

Hi Yoshi, thank you very much for your answers. Please see my comments
below.

OK.

Fine.

>   message as described in Section 4.1.
That's good.

>Yes, it should be finished.
I think it should be specified in the text.

>derive PAMA_MAC_KEY and then immediately terminate the session.
Maybe I didn't understand your answer but AFTER PANA-Bind-X exchange and
in order to remove the session... is it not possible to send PTR/PTA
with a Termination cause related with problem?

>   terminate the session once it receives a PANA-Error-Answer for the
Ok

>logical to use the PANA-Auth-Request(q+1) as an acknowledgement for
Ok then it could be clarified

>PANA request as an acknowledgement for PANA-Ping-Request.
Ah I understand

>So I think the current text is clear enough.
I was thinking in the process: second request(x) arrives then :

-- first look into my cache in order to know sequence number of second
request(x) if this request has a sequence number equal than my cached
answer then it is retransmission. ---> Could we say that it is a
retransmission if sequence number that is expected to receive - 1 is
equal than received request's sequence number?

-- If no retransmission then sequence number verification.

is that correct?

>If Device-Id AVP is an IP address it is the same as IP address of PaC.
I supposed that. Your new text is good for me.

>after the PaC gains access to new link.
Good.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 04 Nov 2004 11:38:43 -0800

> > >      Can we explain the reason why the session cannot be shared
across
> > > multiple network interfaces ?
> > >       I could not find any other place in the document where this
is
> > > explained (perhaps missed it).
> >
> It is still not obvious to me :-) Who is being authenticated ? 

We are authenticating a user/device to authorize network access service
for a given interface.

> Why does
> to the interface) comes into the picture. So, how does it matter to
PANA
> itself ?

DI is bound to the session during the last stage of PANA (PBR/PBA). Even
before the secure association protocol.

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 5 Oct 2004 12:41:15 -0700

Yoshi,

> authentication, isn't it?
The IPsec tunnel mode SA is bound to the inner address and hence the
device identifier should be the inner address. The pana framework draft
talks about this in Appendix A.1, case D where a Update message is sent
after acquiring the inner address. I have not looked for other cases.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 5 Oct 2004 12:51:50 -0700

Rafia,

> without passing through EP/AR.
Yes, it is not possible as the communication between PaC and PAA would not
go through EP at all.

> this traffic. The same happens with the traffic from PAA to PaC.
Agreed.

> there is still only one hop.
In the co-located case, the TTL won't be decremented anyway.Hence, the only
reason you would require is to not to apply IPsec for PANA packets.

> Maybe I am missing something.
No. What happened is that there was only one picture in the beginning and i made
it into two pictures (after our discussion at some point) and then somehow the 
text has not been updated properly.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 03 Nov 2004 00:02:38 -0500

Hi Mohan,

> after acquiring the inner address. I have not looked for other cases.

In the case of A.1, POPA is used for both IPsec-TIA and IPsec-TOA, and
the device identifier is bound to IPsec-TOA (which happens to be the
same as IPsec-TIA.)

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 5 Oct 2004 14:14:13 -0700

> We are authenticating a user/device to authorize network access service
The interface part is not clear to me. It would be good to state the reasoning
behind this.

> before the secure association protocol.
I have been always assuming that for the IPsec case, the DI update happens
after the inner address for the IPsec tunnel has been obtained. EP will check with
this address on every packet and makes sense to use this as the DI.

-mohan

---

From: Alper Yegin <[email-masked]>
Date: Thu, 04 Nov 2004 16:39:03 -0800

Just few points...

> > PANA-Start-Request (as opposed to by a later PANA-Auth-Request)
message
>    layer [I-D.ietf-eap-statemachine].

I had a similar editorial (clarification) comment. I'd say we shall
define what we mean by "stateless" and how we achieve that before the
term appears for the first time in the text. I think it deserves a
paragraph of its own.

...

> logical to use the PANA-Auth-Request(q+1) as an acknowledgement for

Actually I don't feel too comfortable with this optimization. We are
relying on 1- PAR carries EAP, 2- PaC is an EAP peer, 3- EAP peer cannot
generate traffic on its own. These are all true for today. But if any of
them changes in the future, then this optimization breaks things. I
think the design would be more robust if we minimize such cross-layer
assumptions as much as possible.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Thu, 04 Nov 2004 16:55:26 -0800

> The interface part is not clear to me. It would be good to state the

I mean "a network interface". My above statement is based on the
requirement 4.1.1 (see pana-req). Let me know if it still does not make
sense.

> after the inner address for the IPsec tunnel has been obtained. EP
will
> check with

As far as the PAA is concerned, the DI is the IPsec-TOA. And this is
what appears on the (outer) IP header. If the EP is using IPsec-TIA in
filtering traffic due to IPsec mechanics, I think that's fine too. I
hope I'm understanding your concern correctly.

Alper

---

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 4 Nov 2004 17:22:25 -0800 (PST)

--- Alper Yegin <[email-masked]> wrote:

> > > We are authenticating a user/device to authorize
> network access
> service
> > > for a given interface.
> > >
> > The interface part is not clear to me. It would be
> good to state the
> > reasoning
> > behind this.
> 
I am not sure which part of 4.1.1. Could you cut and
paste that here ?

> > > > Why does
> > > > the interface matter ? What if i have
> replicated interfaces i.e, 2
> > > > interfaces
> > > > attached to the same link (RFC 2461
> terminology) ? The secure
> > > association
> > > > protocol is the phase where the IP address or
> MAC address (that is
> > > related
> > > > to the interface) comes into the picture. So,
> how does it matter
> to
> > > PANA
> > > > itself ?
> > >
> > > DI is bound to the session during the last stage
> of PANA (PBR/PBA).
> Even
> > I have been always assuming that for the IPsec
> case, the DI update
> happens
DI by definition :
The identifier used by the network as a handle to
control and
      police the network access of a client. 
Depending on the access
      technology, this identifier might contain any of
IP address,
      link-layer address, switch port number, etc.  of
a connected
      device.

>From the definition, IPsec-TIA is the DI. Are you
saying that we can have two DIs ?

-mohan

---

From: Alper Yegin <[email-masked]>
Date: Thu, 04 Nov 2004 17:40:14 -0800

> I am not sure which part of 4.1.1. Could you cut and

   A PaC's
   identity can be authenticated by verifying the credentials (e.g.,
   identifier, authenticator) supplied by one of the users of the device
   or the device itself.  PANA MUST only grant network access service to
   the device identified by the DI, rather than granting separate access
   to multiple simultaneous users of the device.

> From the definition, IPsec-TIA is the DI. 

Doesn't the IPsec-TOA (PRPA) has any significance to establishing the
IPsec SA, or using IPsec SA? I mean, could I pick a random IP address
(different than the one used as DI during PBR/PBA) and still establish
the IPsec SA and use it? I'm trying to understand....

> Are you

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 6 Oct 2004 10:43:37 -0700

Alper,

>    to multiple simultaneous users of the device.
Okay, you are comparing the "DI" above to the "network interface"
in the pana draft. I don't know why we have to call it "interface" in
the PANA document. Why can't we maintain the same terminology ?
AFAIK, "interface" is used only in one place last time i checked..

> the IPsec SA and use it? I'm trying to understand....
Yes. I don't see any connection between the DI that is used in PBA and
the address used in the secure association protocol. If L2 or L3 security
is used, doesn't the security association protocol that is run after PANA
decide what identifier will be used in access control ? At least it is
true in IPsec case. This means, the DI used in PBA can be useful only
for non-L2-L3 case i.e physically secured links.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 04 Nov 2004 23:17:03 -0500

> AFAIK, "interface" is used only in one place last time i checked..

I agree. We can rephrase the session definition paragraph without
using the term "interface" but using ther term "device identifier".

> for non-L2-L3 case i.e physically secured links.

I am not sure why you don't see any connection between the DI that is
used in PBA and the address used in the secure association protocol.
Are you saying that IPsec-TOA is not associated with the IPsec tunnel
mode SA that is created by the secure association protocol for IPsec,
i.e., IKE?

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Fri, 05 Nov 2004 13:03:10 -0800

Mohan,

> for non-L2-L3 case i.e physically secured links.

Here's how I'm seeing things. 

When crypto-based access control is used, a simple DI is necessary but
not sufficient. It is used along with other identifiers, keys, etc. to
form a complete match criteria.

For example, L2-ciphering enabled after PANA:
- PBR/PBA establishes the MAC addresses of PaC and EP. 
- When the secure association protocol kicks in, PaC and EP can check if
the peer is using the right MAC.
- After the secure association is established, the received data packets
can be quickly eliminated if they are not using the right MAC address.
If the MAC address match, the second line of checks are done using the
authentication hash, etc.

I think something similar to that happens with IPsec-based access
control too. I mean, the IPsec-TOA is part of the filtering, right? Of
course it is not sufficient, because we also need IPsec-TIA, SPI, hash
verification, etc. But I perceive these as the additional checks
required by the crypto-based access control scheme.

That's how DI is in the picture for L2/L3 ciphered access control
schemes (in my view).

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 7 Oct 2004 19:20:49 -0700

> mode SA that is created by the secure association protocol for IPsec,
Yes, that is my basic point. Also, how is DI used in PBA and identifiers in
L2/L3 secure association protocol connected ?

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 7 Oct 2004 19:42:42 -0700

> the peer is using the right MAC.

Yes. But i don't think this is specified anywhere i.e the L2 identifier in PBA and
the L2 identifier in the secure association protocol should be the same.
I don't know why it would be different, but i don't know where it is stated
explicitly.

> can be quickly eliminated if they are not using the right MAC address.

I am not sure how this would be done. In shared medium e.g. 802.11, you
use the MAC address (the identifier of the client) of the client to locate the
state which has the keys etc.  When you receive a packet, all you can tell
is that you received the packet from some MAC address as identified in
the link layer header. You can't discard it until you do the full  checks that
you mention below. So, i am missing something here..

> required by the crypto-based access control scheme.
As far as i can tell IPsec-TOA is used for IKE negotiation and the tunneling
part. When a packet is decrypted, the SPI is sufficient to lookup the
IPsec SA for unicast packets. Both IPsec-TOA source and destination
is not used anywhere within IPsec itself. And i don't know how that filtering
(the first level check) that you mention here works here in the IPsec case.

-mohan

---

From: Alper Yegin <[email-masked]>
Date: Sun, 07 Nov 2004 20:51:46 -0800

> Yes. But i don't think this is specified anywhere i.e the L2
identifier in
> PBA and

This is all about binding the channel (the endpoint addresses being one
parameter) to the established PANA session. Framework I-D does not talk
about this, though it'd be useful to mention there. I think the secure
association specs should mention this.  We have only pana-ipsec for
that.

> use the MAC address (the identifier of the client) of the client to
locate
> the
> the link layer header. You can't discard it until you do the full
checks
> that

If you receive a data packet (non-PANA/DHCP/ND/etc.) whose MAC address
does not match any existing PANA session, you can discard the packet.
You don't need to do any further checks (i.e., crypto verification).

> (the first level check) that you mention here works here in the IPsec
case.

Once an IPsec SA is established, can my PaC send IP packets with any IP
address as the IPsec-ToA? Isn't there any verifications on the tunnel
outer addresses when received by the EP?

Alper

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 8 Nov 2004 07:21:07 -0800 (PST)

> > > When crypto-based access control is used, a
> simple DI is necessary
> but
> > > not sufficient. It is used along with other
> identifiers, keys, etc.
> to
> > > - When the secure association protocol kicks in,
> PaC and EP can
> check if
> > the L2 identifier in the secure association
> protocol should be the
> same.
> > I don't know why it would be different, but i
> don't know where it is
> > stated
> > explicitly.
> 
I am not sure about this. PANA protocol document
discusses about device identifiers and how to convey
using PANA messages. Then, at least the PANA protocol
document should talk about how it is being used. 

> > > - After the secure association is established,
> the received data
> packets
> > > can be quickly eliminated if they are not using
> the right MAC
> address.
> > 
> > I am not sure how this would be done. In shared
> medium e.g. 802.11,
> you
> > state which has the keys etc.  When you receive a
> packet, all you can
> tell
Most likely the crypto is done in hardware and source
mac address is used to locate the keys (in hardwares
that i know of). I still don't see the use for the
above.

> > 
> > > If the MAC address match, the second line of
> checks are done using
> the
> > > control too. I mean, the IPsec-TOA is part of
> the filtering, right?
> Of
> > > course it is not sufficient, because we also
> need IPsec-TIA, SPI,
> hash
> > As far as i can tell IPsec-TOA is used for IKE
> negotiation and the
> > tunneling
> > is not used anywhere within IPsec itself. And i
> don't know how that
> > filtering
> > (the first level check) that you mention here
> works here in the IPsec
> case.
> 
For unicast packets, SPI is sufficient to locate the
SA and once the SA is located, the checks are done
only with the IPsec-TIA. I think this is what many
implementations do. For multicast packets, SPI and
source/destination is used to locate the SA. In that
sense, the IPsec-TOA is used, but mostly for
multicast.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 09 Nov 2004 11:04:01 -0500

Adding one comment to my comment:

>From implementation perspective, explicitly carrying Device-Id AVP
might be good even when non-cryptographic DI binding is used, since
the implementation does not needed to look at MAC header when MAC
address is used as the DI.

Yoshihiro Ohba

> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________